Posts Tagged with "SHA1"

Still using SHA-1 to secure file transfers? It’s time to say goodbye.

Sha-1 Shattered

Securing information is rising in importance for organizations worldwide. Using outdated technology is extremely risky, yet many organizations continue to do so because of legacy systems that don’t allow them to upgrade, lack of resources and time to upgrade, or they are simply unaware. The commonly used SHA-1 algorithm is a perfect example of an obsolete encryption standard that should have been completely phased out long ago. So why are people talking about it today?

With over a decade of warnings about the security vulnerabilities of SHA-1, and deprecation by The National Institute of Standards and Technology (NIST) in 2011, many organizations have since phased out use of this older hash algorithm. For those remaining organizations who haven’t migrated away from SHA-1, Google’s recent public announcement of the first SHA-1 collision should motivate them to abandon this algorithm completely.

Hash algorithms are widely used for a variety of functions including authentication and digital signatures. With file transfers, the algorithm was typically utilized to verify the integrity of sent messages. Using SHA-1, files are compressed into a 160-bit message digest or hash file which is calculated both before and after transmission. On receipt, the two hash values (or signatures) for that transmission are checked to ensure the data has remained intact, as long as both values still match. If the hash values don’t match, the file was likely compromised at some point along the way.

Having two different messages that produce the same hash value should be almost impossible. However, advancements in technology and computational power since the introduction of SHA-1 have exposed its vulnerabilities. With last week’s announcement, Google has proven that systems using SHA-1 can be fooled into thinking a signature is valid when it’s not by producing the same cryptographic hash with two different files. By publicizing their work, this legacy algorithm has been rendered obsolete and insecure.

How does the SHA-1 collision affect file transfers?

If you are still using SHA-1 to verify the integrity of file transfers, you should know that it is no longer considered a safe or secure method. Bottom line, if you still use SHA-1, it should be transitioned to a more secure standard as soon as possible.

If you’re looking to replace SHA-1, an obvious alternative would be SHA-2. The SHA-2 algorithm is a family of hash functions with values of 224, 256, 384 or 512 bits, thus providing stronger security with longer message digests. The more complex algorithms generate more potential hash combinations than were possible with SHA-1 which make the SHA-2 algorithm extremely difficult to break using today’s technology.

GoAnywhere Managed File Transfer and SHA-2

GoAnywhere MFT fully supports the SHA-2 algorithm for secure file transfers over SFTP and FTPS. In addition, GoAnywhere is Drummond Certified for AS2 file transfers and successfully met all requirements for the optional AS2 secure hashing algorithm 2 (SHA-2) tests.


SHA-2 and TLS Security for AS2 Transfers

2016 is a pivotal year for organizations to upgrade the security used to protect their AS2 data transfers. In order to be compliant with the latest security standards, you need to be using a modern AS2 solution.

The End of SHA-1

SHA-1 (Secure Hash Algorithm) is a cryptographic hash algorithm created by the NSA and published in 1995. SHA-1 takes a message of any length and produces a 160-bit message digest. The message digest verifies the integrity of the message by comparing the hash that was calculated before and after message transmission. For example, the hash of a transmitted file is compared against the hash of the file before it was sent. If the hash values are the same, the file was not tampered with. If the hash values are different, the file was altered during transmission. In 2005, attacks have demonstrated the security in SHA-1 is weaker than intended, and a more secure SHA-2 standard was created. SHA-2 is actually a family of hash functions with hash values of 224, 256, 384, or 512 bits. Due to the stronger hash algorithms in SHA-2, Federal agencies have been directed to stop using SHA-1 and must use SHA-2. 2016 is the year software vendors are completing their migration to SHA-2. Google Chrome has begun displaying warning messages for SHA-1 certificates with expiration dates past January 1, 2016, and Microsoft instructed Certificate Authorities to stop issuing SHA-1 certificates earlier this year. Major organizations, like UPS, are requiring their AS2 trading partners to use SHA-2.


Transport Layer Security is a protocol that encrypts communications between client applications and servers. TLS is the successor to the Secure Sockets Layer (SSL) protocol version 3.0, and uses more advanced methods for message authentication, better alerting for problem certificates, and more robust cipher suites. After the POODLE vulnerability was discovered in late 2014, companies that are still using SSL instead of TLS are leaving themselves open to man-in-the-middle exploits. Google and Mozilla have already phased out the support of SSL 3.0 in Chrome and Firefox, and trading partners are demanding companies support TLS for AS2 transfers.

SHA-2 and TLS migration

GoAnywhere MFT fully supports SHA-2 and TLS for AS2 transfers. GoAnywhere is certified by the Drummond Group to validate our AS2 solution follows the RFC 4130 standard and is interoperable with other certified products. Using a Drummond Certified solution, and requiring your trading partners do as well, alleviates the challenges of AS2 and ensures your transfers fully meet the latest security standards. For more information on AS2 support in GoAnywhere MFT, visit the pages on our AS2 Client and AS2 Server.

What is AS2?

Applicability Statement 2 (AS2) is a popular file transfer protocol that allows businesses to exchange data with their trading partners.

AS2 combines the use of several secure and widely used technologies including HTTPS, SSL Certificates, S/MIME, and file hashing. By utilizing the strengths of each of them, AS2 has become the preferred protocol in many organizations for exchanging sensitive EDI files.

AS2 messages can be compressed, signed, encrypted and sent over an SSL tunnel making the file transfers very secure. And receipts can be sent back to the sender ensuring the messages were delivered successfully. The receipts can be digitally signed and will contain a checksum value that the sender will use to verify the message received is identical to what was sent.

Key Features of AS2

  • Message Encryption - By using the recipient's public certificate, the AS2 message contents can be encrypted to keep the data secure. Only the recipient will be able to decrypt the contents using their private certificate.
  • Digital Signatures - The message can be signed using the sender's private certificate which allows the recipient to verify the authenticity of the sender. The receipt that is sent back to the sender can also be signed to ensure the identity of the recipient's system. These digital signatures are used for message integrity and non-repudiation of origin. They are typically used in addition to authentication using a user name, password, and/or certificate.
  • Compression - In order to improve transmission time, compression can be added to decrease the size of the message.
  • Receipt - The Message Disposition Notification (MDN, which is commonly referred to as a receipt) plays an important role in AS2 as it acknowledges that the recipient received the message. It can also be used to verify the identity of the recipient when the receipt is signed. Receipts that are sent back immediately over the same connection are referred to as a synchronous MDN. Receipts can also be sent back at a later time in asynchronous mode. This allows the recipient to process and verify the data before sending back a status to indicate if the transaction was successful.
  • Message Integrity Check - The recipient will calculate a checksum of the message using MD5, SHA1, or a SHA2 hashing algorithm. This value is referred to as the MIC and is shared with the sender by placing it in the receipt. The sender will calculate a checksum as well using the same algorithm. These two values are then compared to guarantee that the message sent is identical to the message that was received.
  • Non-repudiation of Receipt -The use of signatures on the message and receipt creates a Non-Repudiation of Receipt (NRR) event, which is considered legal proof of delivery.

Challenges with AS2

Both organizations will need an AS2 solution in order to exchange data. Due to the complex nature of the AS2 protocol with encryption, signatures, and receipts; it is possible that there can be compatibility issues between two separate products. Fortunately, Drummond Group has a rigorous program that validates an AS2 product follows the RFC 4130 standard and is interoperable with other certified products. Using a Drummond Certified solution, and requiring your trading partners do as well, alleviates the challenges of AS2 and allows you to focus on the business aspects of data transfers.

GoAnywhere MFT is Drummond Certified™ for AS2 and supports SHA2 algorithms for stronger security, chunked transfer encoding to handle large files, multiple attachments per message, and filename preservation.