AS2 has been out for a while, but I bet most of you have never heard of this EDI protocol. Indeed, a couple of months ago, I was oblivious to it. That is until we started building a first-class AS2 Connector. Now that I understand what AS2 is, I will share with you the benefits of this EDI protocol.
AS2 (Applicability Statement 2) is a protocol that operates over HTTP/S and is typically used between organizations to exchange business data in any format securely. The exchange of business data for the purposes of purchasing goods and services is commonly referred to as B2B communication. Traditionally, B2B was done over VANs (Value-added Networks) that were secure and reliable, however, also expensive. The Internet provided a cheaper option. Yet HTTP is not sufficiently secure. Now you might be saying, “You have HTTPS for transporting sensitive data”. Well, for one thing, HTTPS protects your data while in transit from point-to-point, not end-to-end. It’s possible that a document intended for your partner passes through an HTTPS intermediary such as a gateway owned by a third-party:
AS2 File Transfer Provides Security
After the gateway’s HTTPS software peels off the request’s security layers, the document is open for reading and modification with potentially harmful consequences. End-to-end security requires a higher level protocol and this is where AS2 comes into play1. AS2 relies on S/MIME to offer encryption and signing capabilities, protecting the document throughout its entire journey across the network from unauthorized recipients and tampering. Moreover, digital signatures give confidence to the recipient that the sender is really who it claims to be. AS2 processes for securing the data and reading it are depicted as follows:
To secure the document, the AS2 sender:
- Signs the document with its own private key
- Generates a session key and encrypts the document along with the digital signature using the generated session key
- Encrypts the session key with the receiver’s AS2 certificate and includes the key in the request
On the other end, the AS2 receiver:
- Decrypts the included session key with its own private key
- Uses the session key to decrypt the document
- Verifies the document’s signature using the originator’s certificate.
Note the certificates are usually exchanged out-of-band, as part of setting up a bilateral trading partner agreement. Consequently, AS2 normally requires some manual setup (unlike other protocols, such as TLS/SSL).
Having solid evidence that your partner actually received the document you sent is another good reason why you might want to transport documents through an AS2 connection. Consider the gateway example. You send a purchase order for 1000 widgets over HTTPS to the manufacturer. An encoding bug in the gateway software causes it to add an additional zero to the order amount:
You get a 200 OK HTTP status code confirming the order was processed, so you presume the manufacturer received the order as it was sent. The next month, to your surprise, you find 10,000 widgets delivered to your doorstep. Quite reasonably, you refuse to settle the bill, complaining the number of widgets is substantially more than the amount you ordered. The manufacturer, also quite reasonably, demands payment for the widgets they shipped to you. Given that no party has irrefutable evidence contradicting the other, there is no easy way to find out who should bear responsibility for this disagreement.
Disagreements like the one just mentioned are extremely improbable, if not impossible when businesses are communicating over a fully secure AS2 channel due to the use of Message Integrity Checks (MICs) and receipts as well as digital signatures. Below is the high-level view of how AS2 achieves this state of affairs without encryption:
Before sending an HTTP POST containing the document, the AS2 sender:
- Calculates a digest, the MIC (Message Integrity Check), over the document and records it for later use
- Signs the document with its own private key.
Once the document is received the AS2 receiver:
- Verifies it with the sender’s public key
- Creates a receipt, called an MDN (Message Disposition Notification) in AS2 lingo, confirming the document was received and whether it was successfully verified
- Re-calculates the MIC over the received document and adds it to the MDN
- Signs the MDN with its own private key and sends it to the sender
- The sender verifies the MDN with the partner’s public key and compares its recorded MIC against the receipt’s MIC.
Message Disposition Notifications Provide Receipt Verification
Let’s revisit the previous example. Given the above steps, should the gateway modify the purchase order, the manufacturer would immediately know that the order was altered during transit because a signature mismatch would occur. In such a scenario, the manufacturer would return to the sender an MDN stating the document failed verification. Even if the manufacturer accidentally or maliciously changed the ordered amount after delivering a successful MDN, the manufacturer would be forced to claim responsibility. The reason is simple: the manufacturer sent an MDN acknowledging receipt of the purchase order in addition to its content. This property where the manufacturer cannot deny receiving the order as sent by you is known as non-repudiation (or NRR in short). AS2, in its full glory, can help provide NRR of origin and receipt.
AS2 Protocol Efficiency Benefits
Till now, I’ve discussed the security aspects of AS2. What about efficiency? AS2 has an option such that you can have the receiver deliver an MDN asynchronously, as opposed to delivering it in the same HTTP session as the sender’s original message. This option is specified as an AS2-specific HTTP header and it provides two major benefits:
AS2 Reduces the Risk of HTTP Response Timeout
Reduces the risk of an HTTP response timeout. This is especially of value when decrypting and verifying large documents.
The receiver processes the document at its own pace. Fewer resources can be allocated to the receiver for decrypting and verifying the data since the HTTP response time is no longer a crucial factor.
Below, we have an illustration of how async MDNs work, given the document is encrypted and signed:
As you can see above, the recipient replies with a 200 OK as soon as it receives the request. The HTTP response only acknowledges that a request was received; not that its content was decrypted or verified. Asynchronously, the recipient goes on to decrypt and verify the document. Once it’s done, it:
AS2 Creates an MDN
Reads the URL from the AS2-specific HTTP header in the request specifying the destination for the async MDN
Posts an HTTP request carrying the MDN to the URL.
In addition to async MDNs, compression is another efficiency feature in AS2’s arsenal. When signing is applied, compression can occur before or after the data is signed. Benefits exist to both ways of doing things but I’ll leave that discussion for another blog post.
This concludes a 10,000 foot-view of AS2. Now you what is AS2 and why it’s important in business-to-business communication. Considering its security, non-repudiation, and efficiency features, you can see why AS2 is the way to go for doing business over the Internet. Stay tuned to this blog for more of my technical ramblings, other stuff that interests me, and all things ModusBox from the developer’s perspective.
1WS-Security is another way where end-to-end security can be provided. But while AS2 is format agnostic, WS-Security is SOAP specific.
