• What is SSL?
• Why SSL?
• How does SSL works ?
• SSL and firewalls.
• Implementation libraries of SSL
• SSL advantages.
• SSL disadvantages.
• Attacks on SSL.

 How does SSL work ?  
SSL is placed on top of the TCP/IP layer and below the application layer. To set up a SSL connection a TCP/IP connection must be established first as SSL uses the primitives of the TCP/IP. The SSL connection can be seen as a secure channel within the TCP/IP connection in which all traffic between the application peers goes encrypted.  

All the calls from the application layer to the TCP layer are replaced with calls to the SSL layer, and the SSL layer will take care of the communication with the TCP layer. 

This is how the stack looks like when we have put in  SSL into it and as we can see is SSL actually divided into two different layers with the SSL Record layer just on top of the TCP layer: 

----------------------------------------------------- 
Application Layer 

Change Cipher  Alert Protocol     Handshake protocol 

SSL Record Layer 

TCP Layer 

IP Layer 
-------------------------------------------------- 

In the SSL Record layer the messages are divided/combined to fit within the payload of  SSL records, a MAC is created and then is the whole record layer message encrypted with the secret key algorithm agreed upon. The substance of the SSL records will be: content type, protocol version number, length, data payload, message authentication code( MAC ,provides for dataintegrity). The messages are then sent  to the other peer through a TCP/IP connection. 

An  SSL session starts by following a handshake sequence that may vary depending on if the client and server has been in contact with each other before, if certificates are required or not, if an old session is resumed.  

During the handshake there is a  negotiation of what Cipher Suite to use during data transfer, establishment and sharing of the session key between the client and server and optionally authentication of the peers. The Cipher Suite consists of what methods to use for Key Exchange, Data Transfer and creation of Message Authentication Code, MAC. In the table below you see what methods are defined in the SSL v3 protocol. We have seen a description of different cryptographic algorithms earlier in this report. 
 

Session Key Exchange Algorithms, used during handshake:  
NULL,RSA,Diffie-Hellman RSA,Diffie-Hellman DSS,DHE_DSS, DHE_RSA,DH_anonymous, Fortezza/DMS 

Secret Key Algorithms for encryption:  
NULL,  RC2,  RC4, IDEA, DES, 3DES, Fortezza  

Hash Algorithms for MAC:  
NULL , SHA , MD5  

Certificates types: 
X.509 v1,X.509 v2,X.509 v3 
 

When starting up an SSL connection do the peers not know each other so the encryption and MAC algorithms are set to SSL_NULL_WITH_NULL_NULL, indicating that no encryption or message authentication is performed. The peers will have to agree upon how to do encryption/decryption and how to create a MAC. They exchange a Premastersecret,  this is done with any of the key exchange algorithms available: RSA, Diffie-Hellman or Fortezza-DMS. 

When receiving the PreMastersecret, a Mastersecret is computed and the PreMastersecret is erased from memory. This MasterSecret is used to generate key material, which is partitioned to the following secrets and keys:  
· client write MAC secret 
· server write MAC secret 
· client write key = server read key 
· server write key = client read key 
· server write Initialisation Vector, IV 
· client write IV 
These secrets and keys are specified in the CipherSpecs and can be used during the session. 

There are differenet SSL protcols used during the handshake sequence and all of them can be seen as higher level clients of the SSL Record protocol. Each protocol have specific types of messages that are sent using the record layer. The SSL protocols are:  

*Handshake protocol  
-to produce the cryptographic parameters of the session state. 
*Change cipher spec protocol  
-to signal transistions in the ciphering strategies. 
*Alert protocols  
 -closure alert  
 -error alert 

We will take a closer look on these protocols to understand what situations they are used in.  

The Handshake protocol in use : 
Client   Server 
Send ClientHello:Struct{    ProtocolVersion client_version;    Random random;    SessionID session_id;    CipherSuite cipher_suites<2…2E16-1>;    CompressionMethod compression_methods<1..2E8-1>;} ClientHello Rec 
Rec ServerHello: Struct{    ProtocolVersion server_version;    Random random;    SessionID session_id;    CipherSuite cipher_suite;    CompressionMethod compression_method;} ServerHello Send 
Rec Certificate: (optionally)  Struct{    ASN.1Cert certificate_list<1..2E24-1>;} Certificate Send 
Rec ServerKeyExchange message: (optionally)Is sent if server has no certificate, has a certificate only for signing (DSS,signing only RSA) or Fortezza/DMS key exchange is used.This message is not sent if server certificate contains Diffe-Hellman parameters. Send 
Rec CertificateRequest: (optionally)Is sent if a non-anonymous server wishes to authenticate client.Struct{    ClientCertificateType certificate_types<2…2E8-1>;    DistinguishedName certificate_authorities<3..2E16-1>;} CertificateRequest Send 
Rec ServerHelloDone: to indicate that the end of server hello. Send 
Send Client sends Certificate: (optionally) Rec 
Send ClientKeyExchange: one of the three kinds: DH,RSA,FORT/DMS Rec 
Send CertificateVerify: (optionally) Rec 
Send ChangeCipherSpec Rec 
Rec ChangeCipherSpec Send 
Send Finished(hashvalue) Rec 
Rec Finished(hashvalue) Send 
 Now application data is transported, divided into SSL record-layer messages. Compressed and encrypted as agreement in handshake.  
 

The Change cipher specification protocol is used when the handshake is done and the transferrance of data is about to take place. It can also be used when the peers want to change the cipher specification to use, this is good when long time has passed with the same secure channel open.  

The Alert protocols are used when some peer wants to shut down the connection or if one of the peers has detected some error in the transferrance, authorization or something else. 

After the handshake does the the actual communication take place, the transferrance of data. A MAC is computed, with master/client MAC write secret, for the data. The record is loaded with: data to send, MAC, sequence number, content type, protocol version number and length. The whole record is encrypted with the server/client write key using any of the secret key algorithms available. The receiver decrypts with client/server read key och computes MAC to check integrity. 

SSL and firewalls 
If we have a communication from a peer inside a firewall to a peer outside the firewall, what will then happen with the communication when it passes the firewall? It depends on what type of firewall we are using, a firewall working on application level(proxy) or on the network level (packet filtering).[ ] 

Layer   Client  Firewall  Server 

App layer   \/  /\>\/  /\ 
SSL layer   \/  /\  \/  /\ 
Transport layer  \/  /\  \/  /\ 
Network layer  \/  /\  \/  /\ 
Data link   \/  /\  \/  /\ 
Physical   \/ > /\  \/  > /\ 

 Fig. Traffic flow in an application level firewall 
  

SSL is used to set up a secure channel between a client and a user and to avoid any kind of "man-in-the-middle" attack, se below. If we have a application level firewall with full proxy function, caching and replication, the SSL protocol will shout: "STOP!", as SSL sees the proxy server as a man-in-the-middle.  

Some proxy firewalls on the market supports the SSL Tunneling CONNECT extension method [ ]. This describes how an SSL connection is set up via normal HTTP, then handshake phase takes place and creates a secure connection via a byte-forwarding tunnel. The proxy has access to the request headers but the traffic in the session is encrypted according to the SSL protocol.  

Layer   Client  Firewall  Server 

App layer   \/    /\ 
SSL layer   \/    /\ 
Transport layer  \/    /\ 
Network layer  \/  /\>\/  /\ 
Data link   \/  /\  \/  /\ 
Physical   \/ > /\  \/  > /\ 

  Fig . Traffic flow in a packet filtering firewall 

If the firewall works on the network layer, a packet filtering firewall, it will be much easier to set up an SSL connection, but easier often means less secure. This type of firewall is set up to open a reserved and trusted port for the SSL connection, port 443 for SSL with HTTP, port 563 for SSL with NNTP or port 995 for SSL with POP3. All traffic on the port is now allowed to pass through unrestricted. That works fine if there are only SSL capable servers listening on this port , but what will happen if an internal attacker sets up her own connection through this port? There is no way for the firewall to check what type of traffics passing by, a security hole has been opened and the firewall administrator will close this port as soon as he finds out that.  

  
  Client   Cleartext Firewall  SSL  Server 

If the Intranet is considered to be very secure,  all users are trustable and all wires are protected so no one can break in to them, there is another possible solution to implement. Let all traffic on the go unencrypted and let the firewall have the responsibility to set up an SSL connection. In this case we miss the peer to peer authentication, it is only possible for an outsider to authenticate the firewall and thereby the use of certificates miss some or all of its strength.  
  

  
Client   SSL   Firewall  SSL  Server 
  

Yet another possibility is letting  the proxy server hold both client and server keys for its internal clients. When setting up a connection between a client and a server there is actually two SSL connections that are set up, one between client and proxy and on between proxy and server. Now the proxy server can listen to the traffic but just imaging what a delay it means packing up and packing down every single packet passing by. 

The problem with a firewall between client and server can, as we have seen, be solved in different ways, none of them is really the most optimal. We will have to wait and see what future has to show us. 
 

Implementation libraries of SSL  
Implementing security into an application with SSL can be done from scratch with the draft as guiding but it will save a lot of time if there is an available implementation library available. Lucky us there several, both commercial and freeware.  

· SSLref :[ ] Netscape has developed this reference implementation of the SSL protocol. This software library  distributed in ANSIis C source code and can be compiled on several platforms as Win95/NT and Solaris. It is on the market, free for noncommercial use but hard to get for non US citizens as the package falls within the hard export restrictions[ ]. 

· SSLplus:[ ] When the work with SSLref, se above, was finished the work went on by Consensus Development Corporation and they came with this software implementation package that implements SSLv3. To be able to use SSL plus the user has to purchase a license of RSA BSAFE cryptographic toolkit [ ] and this one falls within the export restrictions. 

· SSLava: [ ] an implementation package for the Java programming language. 

· SSLeay:[ ] Freeware, widely available and widely used. A more exhaustive description below. 
 
SSL – advantages, disadvantages and  security analysis 

SSL is the protocol that we have found out to be the most convenient. We have here the most important aspects that has made us choose the SSL protocol.  
 Advantages  
When implementing securiry with SSL you place on top of the TCP/IP layers and substitute TCP calls with the SSL calls. It is independent of the applications once you have set up a connection, after the initiating handshake, it acts just like a secure tunnel and you can send anything through it. 
There exists several implementation packages, both commercial and freely available ones. Implementation packages are available for several platsforms as Unix, Linux, Windows NT/95 and others. That means that many people and companies has done implementation of SSL. Many products as webservers (Apache) and browsers (Netscape Commmunicator, Internet Explorer …) has support for SSL. That has lead to that more and more people using SSL and SSL is a de-facto standard. 
The Internet Engineering Task Force, IETF, has started a working group for SSL and the name of that group is TLS Transport Layer Security, and the work in that group will lead to a standard. 
SSL has all available security functions we want to have to make the project secure: authentication, session key exchange with asymmetric methods, encryption with symmetric methods, MAC, certificates 

 Disadvantages  
SSL is placed just on top of the TCP/IP layers, you substitutes the TCP calls with the SSL calls and that means that the programmer of the implementation has to know a lot about the OS and its specific system calls.  

 Security analysis of SSL  
There are always people,like Trudy, out there wanting to read encrypted data that one peer, Alice, sending to another peer, Bob. In other cases Trudy might want to make Bob believe that she is Alice to make him send something that Trudy can decrypt. Or Trudy want to make Bob take some action that gains Trudy in some way. There are many things to think about and the main aspects we are looking is  privacy, authentication, integrity. 
 Depending on what security protocols and cryptographics algorithms used there are different ways to attack the communication. Attacks that might be used against the SSL protocol are: Cracking Ciphers, Clear Text Attack, Replay Attack and  Man In The Middle. These attacks are described exhaustively in many books and we will only give short explanations of them here and how SSL can resist these attacks or make them harder. 

· Clear Text Attack 
 

      Alice      Bob 
 

    Trudy   Bob  
 
 

              Dictionary  

This attack is used when Trudy has an idea of what is sent and whenit was sent. For example, a Telnet connection always start with "login name:", Trudy snoops the first part of the sent data and identifies that with the clear text. Trudy gather information in a dictionary, the data in the dictionary can be used to check what the encrypted data represents in cleartext and the contents in the dictionary can be extended as time goes by.  When the session key has been identified, the entire message can be decrypted. 
SSL is often usen when implementing security to a HTTP application, FTP application, SMTP application or some other common application. These use protocols with wellknown initiating phrases, it is easy to snoop something on the net, translate to cleartext and build a dictionary and so on.  
SSL is trying to defeat this attack by using large session cipher keys. This can be done in two ways. Have large key lengths, but this is not permitted everywhere. It can be solved in another neat way, generate a large key and send part of it in cleartext to the other peer and when the secret part has been delivered as well, concatenate the two parts and the key has a great strength . With large session keys the dictionaries will become abnormally big and it will not be possible to perform such attack as it takes to much time and hardware. 

· Replay Attack 

      Alice      Bob 
 

    Trudy   Bob  
 

As the name and the picture reveals is this attack of the type where Trudy listens to the communication from Alice to Bob, she records the message and  on a later occasion she replays the message to Bob. An example of this attack type can be an employee, Trudy, that wants to have the monthly salary payed twice to her bank account. 
SSL defeats this attack by using a nonce, a one-time unique number, this is the connection id. Each record sent has a sequence number and for each record sent, either by Alice or Bob, the sequence number is increased. To avoid that the sequence number are set to 0 for each connection between two parts,  SSLeay has the ability to save a session and the next time the connection is up the sequence number just increase from the last saved number.  
 

· Man In The Middle 
 
 

       Alice   Trudy   Bob  

If Trudy cuts the line between Alice and Bob and connects her self in the middle, she might pretend to be Bob when talking to Alice and pretend to be Alice when talking to Bob. When Alice is sending confidential data to Bob, Trudy can intercepts it and change the data to her advantage and then sends the new data to Bob and does the same thing with traffic from Bob to Alice, she acts as the man in the middle. 
SSL defeats this type of attack by the use of server certificates. During the handshake the server’s certificate is sent to the client, this certificate is signed by a certificate authority, CA, ie encrypted with CA´s private key. The client verifies the certificate by checking the signature to see that the issuer of the certificate is someone the client trusts. The name of the certificate issuer is contained in the certificate as well as the name of the server and the servers public key.  The server encrypts something with his private key and it can be decrypted with the public key that is included in the certificate. This will function as a challenge sent from client to server or vice versa.  
To perform a man-in-the-middle attack Trudy must have access to the certificate, the private key to respond to the challenge and to decrypt the session key.  
 

  The "SSL Protocol, Version 3.0",   HYPERLINK http://home.netscape.com/eng/ssl3/draft302.txt     
  

SSL information 
  How SSL works,   HYPERLINK http://home.netscape.com/assist/security/ssl/howitworks.html     

  Phaos, SSL Resource Center,    HYPERLINK http://www.phaos.com/sslresource.html     

  SSL-Talk List FAQ v1.0.3 ,   HYPERLINK http://www.consensus.com/security/ssl-talk-faq.html     

  SSL tunneling CONNECT ,   HYPERLINK http://www.netscape.com/newsref/std/tunneling_ssl.html     
 
  

Implementation libraries: 
  SSLRef,   HYPERLINK http://www.netscape.com/newsref/std/sslref.html     
  

  SSLPlus,   HYPERLINK http://www.consensus.com/SSLPlus/     

  BSAFE3.0, used in SSLPlus,   HYPERLINK http://www.rsa.com/rsa/prodspec/bsafe/bsafe_3_0_f.htm     

 SSLava,   HYPERLINK http://www.phaos.com/solutions.html     
  

Export rules for crypto. 

  Koops, Bert-Jaap, "Crypto Law Survey", version 8.2, May 1997.  
      HYPERLINK http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm     

Standards: 

• IETF-InternetEngineeringTaskForce- TLS page

• alt.security
• Deja News to search newgroups for relevant articles

• The latest edition of this FAQ can always be found at: 
• <http://www.consensus.com/security/ssl-talk-faq.html> 
• <http://www.consensus.com/security/ssl-talk-faq.txt> 

<ftp://ftp.consensus.com/pub/security/ssl-talk-faq.txt

• SSL/SLTP winsock implementation
• Promote.Net- the SSL Protocol
• Free SSL server

• Erming Data , SSL
• Infotorg Sema, SSL
• Ducere -egen implementering av SSL 3.0