SSL

From Network Security Wiki
Revision as of 13:43, 6 January 2016 by m>Amandeep (Protected "SSL" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)) [cascading])
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


HTTPS

  • SSL Session vs Connection:
Session = Server & client has common session identifiers, certificates, compression, cipher suite, master secret.
Connection = Both exchange random numbers, create various keys & parameters for authentication & privacy.
  • SSL has 4 protocols:
1. Handshake Protocol:[1] Negotiate Cipher Suite & exchange information for building cryptographic secrets. It has 4 Phases:
a)Phase 1: Establishes secret capabilities
b)Phase 2: Server authentication and Key exchange
c)Phase 3: Client authentication and Key exchange
d)Phase 4: Finalizing handshake
2. ChangeCipherSpec Protocol
3. Alert Protocol
4. Record Protocol
  • SSL needs:
6 Cryptographic secrets
4 Keys
2 IVs


TLS or SSL Handshake

Source: blogs.msdn.com

Brief Steps
  1. Client & Server exchange 2 random keys
  2. Both exchange 1 PreMaster Secret
  3. Master Key is created from PM Secret by running SHA1 & MD5 several times
  4. Master Key is used to create variable length key material depending on the cipher used
  5. Six different secrets are extracted from key material
Details
        This section needs to be concized.
  • First 3-way handshake occurs.
  • The client will now forward the requests to the Destination IP on port 443 (Default TLS/SSL port).
  • The control is now transferred to the SSL Protocol in the application layer.
  • It has the IP & the Port information handy from previous steps.
  • However, it still has no clue whatsoever about the hostname.
  • The client creates a TLS Packet called as CLIENT HELLO.
  • This contains the following details:
SSL Protocol version
Session ID
List of Cipher Suites supported by the client.
List of CLIENT HELLO Extensions
  • Capture a network trace this is how the CLIENT HELLO would look like:
Handshake Protocol: Client Hello
Version: TLS 1.0 (0x0301)
Cipher Suites (12 suites)
               Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
               Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
               Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
               Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
               Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
               Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
               Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
               Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
               Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
               Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
               Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
               Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Extension: server_name
  • The client sends a CLIENT HELLO to the server on the IP & Port it obtained during TCP handshake
  • Upon receiving the CLIENT HELLO, the server has access to the following information:
IP Address (10.168.3.213)
Port Number (443)
Protocol Version (TLS 1.0)
List of Cipher Suites
Session ID
List of CLIENT HELLO Extensions etc.
  • The Server will first check if it supports the above protocol version and if any of the cipher suites in the provided list. * If not, the handshake fails there itself.
  • The Server will now try to determine if there is an end point listening on the IP and PORT.
  • It then finds the certificate hash corresponding to the IP+PORT combination.


  • The Server responds to the client with SERVER HELLO.
  • The Server typically responds back with the following details:
SSL/TLS Protocol version.
One of the cipher suites from the list of cipher suites provided by client. (whichever is the most secure)
Certificate of the server (Without the private key of course)
List of SERVER HELLO Extensions.
(OPTIONAL)If the web app associated with this binding requires a Client Certificate for authentication then it would request the client to send the certificate. Here the IIS Sever would send the client the distinguished names of the list of TRUSTED ROOT CA it supports.
  • Below is a snippet of the network trace:
Handshake Protocol: Server Hello
Version: TLS 1.0 (0x0301)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Handshake Protocol: Certificate
Certificate (id-at-commonName=www.kaushalz.com,id-at-organizationalUnitName=Azure,id-at-organizationName=Microsoft,id-at-localityName=Bangalore,id-at-stateOrProvinceName=India,id-at-countryName=IN)
  • The Client uses the SERVER HELLO to perform SERVER AUTHENTICATION.
NOTE
If you captured a network trace for a SSL Handshake you could see the details until SERVER HELLO, after that the encryption begins and nothing would be available and would make sense as the packets are encrypted.
  • The Client uses the data provided from the server to generate a pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate), and then sends the encrypted pre-master secret to the server.
  • If the server had requested for CLIENT CERTIFICATE, then client also signs another piece of data that is unique to this handshake and known by both the client and server.
  • In this case, the client sends both the signed data and the client's own certificate to the server along with the encrypted pre-master secret.
  • If the server had requested for client authentication, the server attempts to authenticate the client.
  • If the client cannot be authenticated, the session ends.
  • If the client is successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret.
  • Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection).
  • The CLIENT & the SERVER send each other a message informing that future messages from them will be encrypted with the session key.
  • It then sends a separate (encrypted) message indicating that its portion of the handshake is finished.
  • The SSL Handshake is done.
  • The Client and the Server send each other messages which are encrypted/decrypted using the session keys generated in the previous step.
  • It is now that the Client sends the actual HTTP Request packet to the Server in the encrypted form.
  • The Server decrypts the request via the symmetric key and generates a response, encrypts it and sends it back to the client.
  • This continues normally for the entire session of secure communication.
  • We can see details in a Packet Capture only until SERVER HELLO.
  • Anything beyond this point is not visible.
  • However, in case of a SSL ALERT we would see some notification which can be viewed in the network traces.
  • If there was a problem during the SSL Handshake then you there would be an exception raised within the SSL Layer using SSL ALERT PROTOCOL.
  • These exceptions may or may not be fatal i.e. not all exceptions would cause the handshake to fail.



References
  1. ↑ www.zscaler.com



{{#widget:DISQUS |id=networkm |uniqid=SSL |url=https://aman.awiki.org/wiki/SSL }}

Retrieved from "https://aman.awiki.org/wiki/SSL?oldid=37"