AS1, AS2, AS3 - The AS2 Protocol (Enterprise only)
The AS2 protocol is based on HTTP. It was the second ASx protocol developed
and uses the same signing, encryption and MDN conventions used in the original AS1 protocol.
AS2 is the most popular of the ASx protocols but usually requires more work
to set up than AS1 or AS3.
Like any other ASx file transfer, AS2 file transfers typically require both sides of the exchange
to trade SSL certificates and specific "trading partner" names before any transfers can take place.
AS2 trading partner names can be any valid phrase.
Unlike any other ASx file transfer, AS2 file transfers offer several "MDN return" options
instead of the traditional options of "yes" or "no". Specifically, the choices are:
- Return Synchronous MDN via HTTP(S) (a.k.a. "AS2 Sync") - This popular option allows AS2 MDNs to be returned to AS2 message sender clients over the same HTTP connection they used to send the original message. This "MDN while you wait" capability makes "AS2 Sync" transfers the fastest of any type of ASx file transfer, but it also keeps this flavor of MDN request from being used with large files (which may time out in low bandwidth situations).
- Return Asynchronous MDN via HTTP(S) (a.k.a. "AS2 Async") - This popular option allows AS2 MDNs to be returned to the AS2 message sender's server later over a different HTTP connection. This flavor of MDN request is usually used if large files are involved.
- Return (Asynchronous) MDN via Email - This rarely-used option allows AS2 MDNs to be returned to AS2 message senders via email rather than HTTP. Otherwise, it is similar to "AS2 Async (HTTP)".
- Do not return MDN - This option works like it does in any other ASx protocol: the receiver of an AS2 message with this option set simply does not try to return an MDN to the AS2 message sender.
AS2 with Synchronous MDN via HTTP(S)
- You encrypt a data file with the public key on your partner's SSL certificate and sign it with the private key of your organization's SSL certificate as you bundle everything into an AS2 message.
(Both the encryption and signing steps are optional, but should be used when possible.)
- You send the AS2 message to your partner's AS2 server AND WAIT UNTIL YOUR PARTNER RETURNS AN "MDN" RESPONSE.
(Credentials and cleartext message headers may be protected with SSL transport in this step.)
- Your partner will retrieve your AS2 message off his/her AS2 server.
(Credentials and cleartext message headers may be protected with SSL transport in this step.)
- If the message is encrypted, your partner will decrypt it using the private key on his/her SSL certificate.
If the message is signed, your partner will validate your signature using the public key on your SSL certificate.
Your partner will also use the contents of the AS2 message to verify that the data file they now have is
identical to the data file you sent them.
- If you requested an MDN delivery receipt for your data file, your partner will
calculate a cryptographic hash from the data file they received,
sign the hash (and some other information) with the private key on their SSL certificate
and create an MDN delivery receipt message.
(The signing step is optional and controlled by the original message sender.)
- Your partner will send his/her MDN delivery receipt message back as a response to your still-waiting AS2 "send message and get MDN" request. Once you receive this response (or time out while waiting) you will close your connection.
(Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
- You will inspect your partner's MDN delivery receipt message, making sure that
you can verify his/her signature using the public key on your partner's SSL certificate
and that the cryptographic hash calculated from your partner's copy of your data file matches the
same hash calculation from your original data file.
AS2 with Asynchronous MDN via HTTP(S)
- You encrypt a data file with the public key on your partner's SSL certificate and sign it with the private key of your organization's SSL certificate as you bundle everything into an AS2 message.
(Both the encryption and signing steps are optional, but should be used when possible.)
- You send the AS2 message to your partner's AS2 server and close the connection.
(Credentials and cleartext message headers may be protected with SSL transport in this step.)
- Your partner will retrieve your AS2 message off his/her AS2 server.
(Credentials and cleartext message headers may be protected with SSL transport in this step.)
- If the message is encrypted, your partner will decrypt it using the private key on his/her SSL certificate.
If the message is signed, your partner will validate your signature using the public key on your SSL certificate.
Your partner will also use the contents of the AS2 message to verify that the data file they now have is
identical to the data file you sent them.
- If you requested an MDN delivery receipt for your data file, your partner will
calculate a cryptographic hash from the data file they received,
sign the hash (and some other information) with the private key on their SSL certificate
and create an MDN delivery receipt message.
(The signing step is optional and controlled by the original message sender.)
- Your partner will send his/her MDN delivery receipt message back by posting it to your AS2 server.
(Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
- You will retrieve your partner's MDN delivery receipt message off your AS2 server.
(Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
- You will inspect your partner's MDN delivery receipt message, making sure that
you can verify his/her signature using the public key on your partner's SSL certificate
and that the cryptographic hash calculated from your partner's copy of your data file matches the
same hash calculation from your original data file.
AS2 with (Asynchronous) MDN via Email
- You encrypt a data file with the public key on your partner's SSL certificate and sign it with the private key of your organization's SSL certificate as you bundle everything into an AS2 message.
(Both the encryption and signing steps are optional, but should be used when possible.)
- You send the AS2 message to your partner's AS2 server and close the connection.
(Credentials and cleartext message headers may be protected with SSL transport in this step.)
- Your partner will retrieve your AS2 message off his/her AS2 server.
(Credentials and cleartext message headers may be protected with SSL transport in this step.)
- If the message is encrypted, your partner will decrypt it using the private key on his/her SSL certificate.
If the message is signed, your partner will validate your signature using the public key on your SSL certificate.
Your partner will also use the contents of the AS2 message to verify that the data file they now have is
identical to the data file you sent them.
- If you requested an MDN delivery receipt for your data file, your partner will
calculate a cryptographic hash from the data file they received,
sign the hash (and some other information) with the private key on their SSL certificate
and create an MDN delivery receipt message.
(The signing step is optional and controlled by the original message sender.)
- Your partner will send his/her MDN delivery receipt message to an email server via SMTP. Often, this will be your partner's local email server.
(Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
- If the MDN delivery receipt message were sent to your partner's local email server, it will now deliver it to your email server using the SMTP protocol.
Along the way your partner's MDN delivery receipt message may traverse several intermediate email servers as it is relayed across the Internet or corporate email infrastructure.
(The cleartext MDN delivery receipt message is rarely protected with SSL transport if relay servers are involved.)
This step will be skipped if the MDN delivery receipt message was delivered directly to your email server in step #6.
- You will retrieve your partner's MDN delivery receipt message off your local email server using the POP3 protocol.
(Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
- You will inspect your partner's MDN delivery receipt message, making sure that
you can verify his/her signature using the public key on your partner's SSL certificate
and that the cryptographic hash calculated from your partner's copy of your data file matches the
same hash calculation from your original data file.
To support AS2 most sites will typically need to deploy both MOVEit Central and MOVEit DMZ.
MOVEit Central performs all AS2 encryption, decryption, signing, verification and sending steps,
but MOVEit DMZ is required to receive AS2 files or AS2 HTTP-based asynchronous MDNs.
AS2 with Synchronous MDN via HTTP(S)
AS2 with Asynchronous MDN via HTTP(S)
AS2 with (Asynchronous) MDN via Email
See also:
To an outside observer, AS2 is a strange protocol. ("Why would you want to try sending SMIME-encrypted messages and picking up SMIME-signed delivery receipts over HTTP? Isn't that what email is for?")
Its appeal lies largely in the fact that its "sync MDNs" make AS2 the fastest and most discrete of any of the ASx protocols because only one "external" connection between your organization and your partner is required to complete these transactions.
(Any other ASx "transfer file and return MDN" operation requires at least two external connections.)
Advantage: AS2 is the most popular of the ASx protocols. Most people who support any one or two of the ASx protocols support AS2. It is a de facto standard in many industries, and an explicit standard in others (e.g., some pharmaceutical file transfer "pedigrees").
Advantage: AS2 is firewall-friendly when sending files. If you can connect to Internet-based web sites from your desktop, you can probably send AS2 files of any size and receive (synchronous-mode) AS2 MDNs for small to medium sized files.
Advantage: AS2 is the only ASx protocol that allows the sender to ask for an "immediate" (synchronous) MDN response. AS2 allows senders to request immediate, "synchronous" MDN's as part of their HTTP file transmission. Synchronous MDN responses are calculated on the fly as soon as the entire file is received and returned as the response to the file transmission over the same HTTP connection. All AS1, AS3 and "asynchronous" AS2 MDNs are expressed as files to be picked up after the original transmission is complete and closed rather than as an immediate response to the current transmission.
Disadvantage: Synchronous ("immediate") MDN responses are only appropriate for small files. Both sides must usually set up an AS2 server if large files are to transferred. AS2 transmissions involving large files can "time out" (with no "I'll get back to you" recourse) if the files sent are large. (The actual value of "large" depends on available bandwidth and timers in AS2 client, AS2 server and any intervening HTTP proxy server.) To handle large files, AS2 asynchronous MDNs may be requested instead, but these may only be requested if the file sender also owns an AS2 server on which the file receiver can post asynchronous MDNs. (In other words, "desktop AS2 clients" can 1) either send and verify small files with a synchronous MDN or 2) send large files without any MDN or verification.)
Disadvantage: AS2 requires firewall configuration and deployment of a designated AS2 server when receiving files. To receive AS2 files, you must set up your own AS2 server (usually in a DMZ network segment) and open up firewall rules that allow remote AS2 clients to connect to your AS2 server. (MOVEit DMZ fills the role of an AS2 server in the MOVEit family.) Neither AS1 nor AS3 require you to host your own server to receive ASx files.
Disadvantage: AS2 messages may be subject to HTTP proxy rules. In most situations AS2 messages are passed through traditional HTTP proxies, which means they are subject to content filters, size limits, server downtime, banned sites, "header" restrictions and other HTTP proxy issues that people may do not want to involve in file transfers with their partners. (In practice, AS2 HTTP proxy issues tend to be less of a hassle than AS1 email server issues, but "header" restrictions are probably an area to keep an eye on because AS2 depends heavily on special headers.)
Disadvantage: AS2 has no standard concept of "username" or "password" when posting files. ("Two-factor authentication" is not standard.) Both AS1 and AS3 support the traditional file transfer concept of providing a username and password before you are allowed to upload files to the server. AS2 does not. (Some AS2 servers may have implemented "basic authentication", but it is not supported in most AS2 clients.)
See also: Comparison of AS1, AS2 and AS3 on the "AS1, AS2 and AS3 - Overview" page.