TLS Sequence Numbers

When talking about SSL/TLS most of the discussion centers around the ciphersuites, the types of messages or other complex cryptographical aspects. But there are many subtle things embedded in the protocol, which are often skipped or not discussed generally. One such thing is sequence numbers. Like in TCP, a sequence number for messages is also maintained in SSL/TLS protocol and one gets to know only is he/she delve into the RFCs.

In case of SSL/TLS, sequence number is a simple count of messages sent and received. This is maintained implicitly i.e, not sent in the messages explicitly. The protocol requires to maintain a separate sequence number counter for read and write sessions respectively.

A touch of history,  sequence numbers were not used in the SSLv1, and were introduced in SSLv2 only.  Thus making SSLv1 prone to replay attacks (against which sequence numbers protect).

The question arises, if sequence number for a connection is maintained, and given that it is not explicitly transmitted, then how it is useful? To answer, sequence numbers are used in the MAC. To prevent message replay or modification attacks, the MAC is computed using the MAC secret, the sequence number, the message length, the message contents, and two fixed character strings. When either side calculate the MAC for a given message, if sequence number does not correspond to the current message, then message authentication will fail, and the receiver will demand the sender to re-send the message.

From RFC 6101 states following about how sequence number should be calculated and also what data type should be used. Note that by using int64, chances of overflow are minimized.

“Each party maintains separate sequence numbers for transmitted and received messages for each connection.  When a party sends or receives a change cipher spec message, the appropriate sequence number is set to zero.  Sequence numbers are of type uint64 and may not exceed 2^64-1.”

To summarize, the sequence number provides protection against attempts to delete or reorder messages.

References:
[1] https://tools.ietf.org/html/rfc6101#page-14
[2] https://security.stackexchange.com/questions/55667/tls-sequence-number#
[3] SSL and TLS Theory and practice by Rolf Oppliger

KCI attacks against TLS

In past 2 years or so, SSL/TLS protocol is under severe scrutiny and rightly so, as it is one of the most widely used cryptographic protocol on the Internet. How secure place Internet is directly or indirectly do depend on SSL/TLS protocl. In the past there have been many vulnerabilities discovered, ranging from design issues like POODLE, FREAK or LOGJAM to implementation bugs like HEARTBLEED and OpenSSL CCS. Recently in Usenix’15 conference, another attack on TLS was presented – Prying open Pandora’s box: KCI attacks against TLS. Where, KCI stands for Key Compromise Impersonation. Although, this attack is not as severe as other existing attacks, but still as per author’s claim, might affect a tiny part of the Internet. In this post, lets try to understand the how the attack works and what are the ways to protect against this attack.

TL;DR this attack is only possible when the communication is happening using non-ephemeral (EC)DH and client certificates are used for authenticating the clients, and some more conditions thrown in the mix. Use of non-ephemeral (EC)DH is very limited on the Internet and further use of client certificates is also rare, thus making this vulnerability less likely to occur.

Before getting into the details of this attack, it is presumed that readers know about the working of SSL/TLS protocol in general and how SSL/TLS work when non-ephemeral (EC)DH supporting cipher suits are used. Also, understanding how a typical MITM attack against a TLS session works will be helpful.

WORKING:
Before getting into the actual attack phase, there is pre-attack phase in which attacker needs to collect information to carry on the attack.

Pre-Attack Phase: The attacker should be able to get the possession of a client certificate and its corresponding private key that is or will be installed at the client. This might seem to be little unlikely to perform, but authors say it is possible in cases like a  software vendor shipping product with pre-installed client certificates or a malicious Android App installs one on the system etc.

Attack Phase: A client C  (e.g. a browser) initiates a TLS connection to a server S. The attacker M, attacking as Man-in-the-Middle, will block the traffic from C to S. For the ClientHello message sent by the client, M responds with a ServerHello message, choosing a non-ephemeral  cipher suit for communication.

In Certificate message, attacker M sends the original server’s certificate, unlike in a typical MITM attack, a new certificate (not of original servers) is sent. We will see shortly, how attacker derives the master secret, as he does not have the private key of the certificate sent.

The attacker asks for the client certificate by sending CertficateRequest message and requests for non-ephemeral (EC)DH client authentication. In the message, the attacker also asks for the client certificate to be of same type that of the server certificate it sent. In the CertificateRequest message by specifying the CA name, the attacker can ascertain that client uses the compromised pair of certificate and secret key to authenticate itself.

The client proceed to finish the handshake, oblivious of the attack being performed, as it would normally do. While the attacker does not know have the private key of the server’s certificate and hence cannot derive the master secret. But the he knows the secret key, and uses that to calculate the master secret and complete the handshake.

PRE-CONDITIONS:
Lets summarize the pre-conditions to pull off this attack and then see how to prevent such attack:

  1. Client Support: The client must support a non-ephemeral (EC)DH cipher suites, i.e, by sending the (EC)DH protocols in the ClientHello message. Additionally, the client implementation must support any of the fixed (EC)DH client authentication options implied by the client certificate types: rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh.
  2. Server Support: The adversary attacking a server must get possession of certificate of the server that contains static (EC)DH values. There are further subtle details discussed in the paper, like why such attack is possible in case of DSS or ECDSA certificate.
  3. Compromised Client Cert: The adversary must have possession of a client certificate and the corresponding secret key that must both be installed at the client.

PREVENTION:
On server side:

  1. Disable non-ephemeral (EC)DH handshakes
  2. “Set appropriate X509 Key Usage extension for ECDSA and DSS certificates, and disable specifically the KeyAgreement flag.”

In the paper authors have went on to motivate why this attack at present might be unlikely but still possible in future scenarios. IMHO, this might not be the most sorted after attack vector, but surely such research ensure that TLS protocol will become more secure in the future.

Keep Hacking 😀

What is POODLE and how to detect it

SSL was again center attention recently. After series of vulnerabilities, Heartbleed and OpenSSL CCS to a count a few, another vulnerability rocked one of the most important communication protocol of the internet. POODLE, Padding Oracle On Downgraded Legacy Encryption, affects SSLv3 (RFC6101) protocol and assigned CVE-2014-3566. SSL 3.0 is an old protocol, proposed by Netscape in 1996 and now have been succeeded by new protocols, TLS 1.0, TLS 1.1 and TLS 1.2. SSL 3.0 is obsolete now and only supported because many legacy systems still use it. For example, some old embedded devices still use it and it is not very straightforward to update such devices. But after surfacing of POODLE attack, it is highly recommended to disable SSL 3.0 for any form of communication. After the demise of IE 6, all the modern browsers support TLS 1.0 and thus it is safe and logical to deprecate this old protocol.

POODLE hogged the most of the limelight, but in the OpenSSL advisory there were some more bugs reported, which should also be taken care by the administrators and the users. In total there are 4 bugs disclosed, other than poodle, rest 3 relates to implementation issues in OpenSSL. It is highly recommended to update your OpenSSL library version if you are using it.

POODLE:
SSL is a very big and complex protocol. I tried to cover the basics of SSL/TLS protocol in the previous posts. Most of the complexities lies in the initial handshake phase, where various protocol parameters like protocol version, ciphersuite, compression etc are negotiated. POODLE attack is concerned with the next phase of the SSL protocol, the bulk encryption phase, where the communication end points have already established the SSL connection and ready to exchange application’s data, e.g HTTP request and responses. POODLE is the latest in a long line of similar attacks against known weaknesses in SSL’s use of Cipher block chaining (CBC) mode for block ciphers used in encryption. It is important to note that POODLE is more of a design issue than an implementation bug, unlike previous bugs like Heartbleed and OpenSSL CCS vulnerability. Some excellent explanation about the working and explanation of the attacks is available at following places:

– The security advisory(https://www.openssl.org/~bodo/ssl-poodle.pdf) by the authors of the attack, Bodo Moller, Thai Duong and Krzysztof Kotowicz.
– Thomas Pornin explaining  very succinctly at security stackexchange.
–  A detailed explanation of the vulnerability and its history .
This and this contains information about configuration changes in various servers and browsers to be taken care of in order to protect against POODLE.

THE WOKRAROUND:
There are couple of workarounds suggested by experts. One recommended by most is to outright totally disable SSLv3. As argued, it is a very old protocol and now most modern devices support its successor, thus it makes sense to do so. But if this is not an option, then using TLS_FALLBACK_SCSV proposal by Google’s Adam Langley is another option.

SCSV stands for “signaling cipher suite value”, and its essentially a hack which allows TLS clients to indicate to servers that they support some extensions to TLS, while ensuring that servers that don’t understand the extension will simply ignore. SCSV works by appending a special, bogus value to the list of ciphersuites that the client advertises support for. The working of this proposal is a IETF draft and not standardised yet, but many implementation are supporting it
now.

The working of SCSV is very simple, but tend to confuse in the first shot. In case of an attack via downgrading the SSL version, TLS_FALLBACK_SCSV indicates that the client is knowingly repeating  a SSL/TLS connection attempt over a lower protocol version than its supports, as the last one failed for some reason.  When the server sees this TLS_FALLBACK_SCSV in ciphersuite list, it compares the highest protocol version it supports to the version indicated in the Client Hello. If the client’s version is lower, then the server responds with a new Alert defined by the RFC called ‘inappropriate_fallback’ (code 86). The logic being that the server knows the client supports something better so the connection should have negotiated that. The ‘inappropriate_fallback’ Alert is a “fatal” error and the connection attempt should be aborted. In practice, this protects from all forced downgrades attack completely. Unfortunately, this is not the silver bullet to the problem. In case the client-server negotiate SSLv3 protocol then this attack can be carried out. To further read about TLS_FALLBACK_SCSV, you can visit here  and RFC draft.

HOW TO DETECT:
The detection is also straightforward. Send the TLS_FALLBACK_SCSV {0x56,0x00} in the list of supported ciphersuites in the Client Hello, if the server responds with an alert message inappropriate_fallback, then the server is not vulnerable to downgrade attack. Additionally, it is best if the server does not support SSLv3 outright.

Keep hacking!! 😀

Dissecting TLS Client Hello Message

In the previous post, I discussed about how TLS session is established. In the course, I also introduced to various sub-protocols involved in TLS protocol. In this post, I will look into various parameters of client_hello message. But before get going, I will lay down some basic blocks and talk about TLS Record Protocol and TLS Handshake Protocol. client_hello message is part of TLS Handshake Protocol.

One thing to always keep in mind is during a TLS session negotiation all the data exchanged is unencrypted and goes in plain text. Only post this negotiation stage, the data exchanged is encrypted.  During session negotiation, the messages exchanged can be intercepted by an eavesdropper and derive information which can help in identifying the user or the domain he/she is visiting. Such attacks are mentioned in this post. Another such resource I came across is this one.

So lets get going by delving into details of TLS Record Protocol. While further reading always remember the block diagram below and ever in confusion revert to this diagram. The crux being, TLS Record Protocol is an envelope protocol. TLS Handshake Protocol, Change Cipher Spec Protocol and Alert Protocol are ‘letter’ of this envelope.

 

TLS's sub-protocols block representation.
TLS’s sub-protocols block representation.

 

TLS Record Protocol:

TLS Record Protocol is a layered protocol. At each layer, messages may include fields for length, description, and content. The Record Protocol takes messages to be transmitted, fragments the data into manageable blocks, optionally compresses the data, applies a MAC, encrypts, and transmits the result.

In RFC 5246 Record Layer message is defined as following :

struct{
    ContentType type;
    ProtocolVersion version;
    uint16 length;
    opaque fragment[TLSPlaintext.length];
}TLSPlaintext;

Lets try to understand each parameter one at a time:

  • type: Record Layer Protocol is envelope to other TLS sub-protocols, Handshake Protocol, Change Cipher Spec Protocol, Alert Protocol and Application Data Protocol. This ‘type’ variable tells which sub-protocol is encapsulated in this record layer message.
  • version: The TLS version being used. For instance, if TLS 1.1 is used, then version will be {3,2}, deriving from the use of {3,1} for TLS 1.0. Note that a client that supports multiple versions of TLS may not know what version will be employed before it receives the server_hello message.
  • length: The length of the TLSPlaintext.fragment in bytes. The maximum length allowed is 2^14 bytes. In simple words, length of the ‘letter’ of this envelope message.
  • fragment: Fragment is the application data. This data is transparent and treated as an independent block to be dealt with by the higher-level protocol specified by the type field.

A simple byte-by-byte representation of record layer message is following:

Byte 0 = SSL record type
Bytes 1-2 = SSL version (major/minor)
Bytes 3-4 = Length of data in the record (excluding the header itself). The maximum SSL supports is 16384 (16K).

Byte 0 can have following values:
SSL3_RT_CHANGE_CIPHER_SPEC 20 (x’14’)
SSL3_RT_ALERT 21 (x’15’)
SSL3_RT_HANDSHAKE 22 (x’16’)
SSL3_RT_APPLICATION_DATA 23 (x’17’)

Bytes 1-2 in the record have the following version values:
SSL3_VERSION x’0300′
TLS1_VERSION x’0301′
TLS2_VERSION x’0302′
TLS3_VERSION x’0303′

TLS Handshake Protocol:

TLS handshake protocol runs on top of TLS Record Protocol. “This protocol is used to negotiate the secure attributes of a session. Handshake messages are supplied to the TLS record layer, where they are encapsulated within one or more TLSPlaintext structures, which are processes and transmitted as specified by the current active session state.”

Following handshake types are supported by this protocol:

  1. hello_request
  2. client_hello
  3. server_hello
  4. certificate
  5. server_key_exchange
  6. certificate_request
  7. server_hello_done
  8. certificate_verify
  9. client_key_exchange
  10. finished

A typical TLS Handshake Protocol should be of following format:

 struct {
          HandshakeType msg_type;    /* handshake type */
          uint24 length;             /* bytes in message */
          select (HandshakeType) {
              case hello_request:       HelloRequest;
              case client_hello:        ClientHello;
              case server_hello:        ServerHello;
              case certificate:         Certificate;
              case server_key_exchange: ServerKeyExchange;
              case certificate_request: CertificateRequest;
              case server_hello_done:   ServerHelloDone;
              case certificate_verify:  CertificateVerify;
              case client_key_exchange: ClientKeyExchange;
              case finished:            Finished;
          } body;
      } Handshake;
  • msg_type: This parameter specifies the type of TLS Handshake protocol message enclosed.
  • length: Length parameter tells about the length of message following in the body.

With all the ground work layed, now we move towards the topic of this post, dissecting a client_hello message.

Client Hello Message:

As evident from above, client_hello message is a type of TLS Handshake Protocol. Structure for client_hello message is defined as following:

struct{
    ProtocolVersion client_version;
    Random random;
    SessionID session_id;
    CipherSuite cipher_suites<2..2^16-2>;
    CompressionMethod compression_method<1..2^8-1>;
    select (extensions_present){
        case false:
            struct{};
        case true:
            Extension extensions<0..2^16-1>;
    };
}ClientHello;

Each parameter in layman terms:

  • client_version: The version of TLS protocol using which client wishes to communicate during this session.
  • random: It is client generated random structure, comprising of 4 bytes of time since epoch on client and 28 random bytes. Exposing timer sources may allow clock skew measurements and those in theory may be used to identify hosts.
 struct{
     uint32 gmt_unix_time;
     opaque random_bytes[28];
 }Random;
  • session_id: This field is empty if no session_id is available. In order to avoid the full process of establishing a TLS connection, the client may reuse previously established session. By providing the session_id the client intents to resume the session with previously negotiated parameters. The session cache is shared between normal and privacy modes of the browser and thus user might be identifiable due to TLS session reuse.
  • cipher_suites: Contains the list of cryptographic options supported by the client and ordered in client’s preference first. Some ciphersuites are proven to be insecure and advised against their use.
  • compression_methods: Contains the list of compression methods supported by the client, and sorted by client preference. Compressing data does save bandwidth.
  • extensions: TLS protocol provides the ability to extend the functionality. Notably some most used are Server Name Indication (SNI),Heartbeat etc. In case of SNI, the remote domain name goes in plaintext and thus, anyone sniffing the traffic can exactly determine which all domains you visited.

A wireshark capture showing various parameters sent for a client hello are shown in the screenshot below.

Wireshark capture showing client hello message.

 

Keep hacking 🙂

REFERENCES:

  1. https://idea.popcount.org/2012-06-16-dissecting-ssl-handshake/
  2. http://tools.ietf.org/html/rfc5246#page-37

 

 

SSL/TLS Session Establishment

In the previous article I talked about introductory facts of SSL/TLS. In this post I will be looking at how a TLS session is established and introduction to internals of TLS protocol.Further in this post it is assumed that TCP is the underlying transport protocol on top of which TLS is working.

TLS consists of two protocols, TLS Handshake Protocol and TLS Record Protocol and can be depicted as in the image below.

TLS Protocol Layers
TLS Protocol Layers

From RFC 5246, the TLS Record Protocol is used for encapsulation of various higher-level protocols. One such encapsulated protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and to negotiate an encryption and cryptographic keys before the application protocol transmits or receives its first byte of data. The TLS Handshake Protocol provides connection security that has three basic properties:

– The peer’s identity can be authenticated using asymmetric cryptography ( RSA, DSA etc).

– The negotiation of a shared secret is secure.

– The negotiation is reliable.

When a TLS session is established, it could be resumption of a previous session between client and server or  totally a new session. Firstly, let us see how a new session is established and then how session resumption works.

TLS new session negotiation:

Post TCP 3-way handshake, TLS session establishment initiates. This can be observed in the wireshark snapshot below.

Wireshark session showing TCP 3-way handshake and TLS session establishment
Wireshark session showing TCP 3-way handshake and TLS session establishment

The client starts the initiation process by sending a Client Hello packet. Client Hello contains vital information like max TLS version supported by the client, cipher suits supported, compression algorithms supported and various TLS extensions supported by the client. Heartbeat is a commonly used extension and Heartbleed bug was present in this TLS extension in OpenSSL library.

On receiving Client Hello, server responds by sending a Server Hello message. Server Hello message contains parameters on which the two ends are agreeing to communicate. These parameters include, TLS version, a cipher suit (chosen from the cipher suits advertised by the client), compression algorithm and TLS extensions which will be used by the two peers. In case the TLS session is being negotiated for the first time, Server Hello may return a Session ID, which can be used in future for session resumption. If Session ID is empty, it implies that server is not willing to resume session in future. In case server does not support any of the cipher suits advertised by client, then a TLS Alert message is sent by the server instead of Server Hello.

TLS handshake overview
TLS handshake overview

The alert sub-protocol is a component of the Handshake protocol that includes event-driven alert messages that can be sent from either party. Following an alert message the session is either ended or the recipient is given the choice of whether or not to end the session. The alerts are defined in the TLS specification in RFC 2246.

In Server Certificate message, server sends a certificate to the client. This certificate is used for authentication of the server and also contains the server’s public key.  The public key is used to encrypt the pre-master secret. If the name of the server in the certificate does not match the URL used by the client to connect, then in most of the popular modern browser a warning message is generated.

Server Key Exchange message is optional. It is used to send a temporary key to the client, which will be used for pre-master secret encryption.  It is used in the situation like the server certificate does not contain the server’s public key.

Client Certificate Request message is also an optional one and used when server requests the client to provide a certificate to authenticate client.

Server Hello Done message is used by the server to indicate that communication from server is finished and now it is awaiting further response from the client.

Client Response to Server:

Client Certificate message is optional and only sent if server has requested for a client certificate. Client certificate contains client’s public key.

Client Key Exchange message is sent after computing the pre-master secret using the two random values sent by client and server respectively in their hello messages. The pre-master secret is encrypted using server’s public key. If the server is able to decrypt it, then client is assured that the server has the correct private key. It is the most important step in the whole process to establish the authenticity of the server and continue further with protocol negotiation.  Message also include protocol version to match against the version sent originally in the Client Hello. This is important to prevent protocol version rollback attacks.

Certificate Verify message is sent only if Client Certificate message was sent previously. This message comprises of hashes of all the messages up till now, encrypted by client’s private key.

Change Cipher Spec (CCS) message notifies the server that all the messages after Client Finished  

Client Finished message consists of hash of all the conversation to further ensure the authenticity of the client. This is the first message that the record layer encrypts and hashes.

Server Final Response to Client:

Change Cipher Spec  message, similar to client’s CCS message, is used by server to notify that from here on server will begin encrypting the messages.

Server Finished message consists of hash of the entire exchange till now using session key and MAC secret. If the client and decrypt and validate the hash, then the TLS handshake process was successful and the keys computed locally at client and server match and are correct.

TLS Session Resumption:

Above we looked into how a new TLS session is established. But establishing a new TLS session is a very CPU intensive and time consuming process. It requires two round trips for a full handshake to complete. If the client and server can cache the Session IDs exchanged between them, it can be used to resume the previous TLS session. In simple words, if the client and server remember the previously negotiated parameters then the communication can be carried on with those parameters itself. To resume a session with a given Session ID is called as abbreviated handshake, described in RFC 5077.  This short handshake is depicted in the flow diagram below.

Abbreviated TLS handshake
Abbreviated TLS handshake

 

Some additional information, CVE-2014-0224 or the CCS Injection attack involves sending the client CCS packet before the master secret is calculated. By doing so, the master secret is based on a weak pre-master secret and hence easily guessable. You can read more about it here.

Thats all for this post, in the next one I will break down Client Hello message and see how the various TLS sub-protocol work.

References: