AS2 is a specification about how to transport data securely and reliably over the Internet. Security is achieved by using digital certificates and encryption.
이하 위키피디아 내용
The AS2 protocal is based on HTTP and S/MIME. It was the second AS protocol developed and uses the same signing, encryption and MDN(Message Disposition Notifications) conventions used in the original AS1 protocol introduced in the late 90s by IETF.
- Files are encoded as "attachments" in a standardized S/MIME message (an AS2 message).
- AS2 messages are always sent using the HTTP or HTTPS protocol and usually use the "POST" method (use of "GET" is rare).
- Messages can be signed, but do not have to be.
- Messages can be encrypted, but do not have to be.
- Messages may request a Message Disposition Notification [MDN] back if all went well, but do not have to request such a message.
- If the original AS2 message requested an MDN:
- Upon the receipt of the message and its successful decryption or signature validation (as necessary) a "success" MDN will be sent back to the original sender. This MDN is typically signed but never encrypted (unless temporarily encrypted in transit via HTTPS).
- Upon the receipt and successful verification of the signature on the MDN, the original sender will "know" that the recipient got their message (this provides the "Non-repudiation" element of AS2)
- If there are any problems receiving or interpreting the original AS2 message, a "failed" MDN may be sent back. However, part of the AS2 protocol states that the client must treat a lack of an MDN as a failure as well, so some AS2 receivers will simply not return an MDN in this case.
Like any other AS 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 usually be any valid phrase.
AS2 is a communication protocol for transferring files from one system to another. (FTP is another example of a protocol used for transferring files.) While it was developed with EDI in mind, it can be used to transport data of any type from system to system.
To send and receive AS2 one must have AS2 software, which acts as both a client (for sending) and a server (for receiving). This is really no different than to need for an FTP client and FTP server when using that protocol. There are multiple AS2 software packages on the market (some even free) and a number of hosted offerings. Each offers different levels of automation, integration and licensing requirements; but what they all have in common is interoperability: any AS2 package should be able to exchange data with any other AS2 package.
When all configured properly, this is what happens in the typical AS2 file transfer:
- The file is received locally by the sender’s AS2 system;
- The receiver system is identified;
- The sender encrypts the file with the receiver’s public key;
- The sender signs the file with the sender’s private key;
- The sender transmits the whole message to the receiver’s AS2 server;
- The receiver identifies the sender by AS2 ID;
- The receiver validates the file with the sender’s public key;
- The receiver decrypts the file with the receiver’s private key;
- The receiver sends an MDN (message disposition notices) back to the sender, encrypted and signed (reverse of the keys above), acknowledging the successful receipt of the file;
- The sender verifies the MDN and the transfer is complete.
Here are a few key features of AS2:
AS2 is HTTP-based. That means it runs as a web server and web client using the HTTP protocol. What differentiates this from using a standard web server is the formatting of the message that is transferred. Many AS2 applications run on top of a standard web server. It can also run over HTTPS (SSL).
Messages sent over AS2 have a specific format, which is handled by the AS2 software. Both successful and unsuccessful transfers receive an MDN (message disposition notice) if requested, allowing the sender to know if the transfer succeeded. MDNs are not proof that the data is valid, but it does confirm the other side received the payload.
Each AS2 “system” has a unique identifier called the AS2 System Identifier (or AS2 ID for short). The AS2 ID must be comprised of 1 to 128 printable ASCII characters and is case-sensitive. This AS2 ID identifies the sender and receiver, and which certificates should be used. It also allows multiple servers to be used for the same AS2 system, for load balancing and for redundancy. There is currently no registrar for AS2 IDs and no guarantee that they are unique from all other systems. It is up to the implementer to make sure they are unique.
AS2 incorporates encryption and digital signatures. Once encrypted, only the intended recipient can read the data, and once signed, there is a high confidence in who actually sent the data. AS2 uses public and private keys and certificates for encrypting and signing messages. The biggest challenge is managing all the certificates and keeping them up to date.
In the early days (2005) the Drummond Group and its certification were critical to getting all the new AS2 developers on board and adhering to the standard. Now the need for that is less as there is plenty of existing AS2 to test new systems against. Either they work or they don’t.
The bigger issue now is in all the various ways “certified” software is implemented by end users, causing all sorts of configuration issues and problems.