CCIE Study Notes

I think the grouping of SSL, TLS and DTLS is pretty obvious. Two items of note: first - both SSL and TLS are sometimes called "SSL" or "SSL/TLS." Secondly, SSL 2.0 was prohibited in 2011 and SSL 3.0 was deprecated (not recommended and heading to the bit bucket) in June 2015. With that in mind, any questions on SSL would be for historical reasons or used as a comparison to TLS. So why did SSL go by the wayside? According to Wikipedia, SSL 2.0 was released in February 1995 and was found to contain a large number of flaws that led to the creation of SSL 3.0. As of 2014, SSL 3.0 was considered insecure because it is vulnerable to the POODLE attack for all block ciphers and RC4 is also feasibly broken as used in this protocol.

I don't want to take up too much time / space with SSL, but there is a Cisco Doc "SSL Introduction with Sample Transaction and Packet Exchange" which covers this thoroughly. I highly recommend reading this doc if you don't thoroughly know SSL. Very important (or interesting) is the diagram of a sample transaction. Looking at this material, if I was going to write a question on SSL, it would be about the Record Types.

There are 4 record types:
Handshake Records
Change Cipher Spec Records
Alert Records
Application Data Records

That's it. I would add as detractors things like Client Hello, Server Hello and Hello Request. All of them are actually Handshake Records. That's probably the toughest question I could imagine on SSL. If you're interested in seeing this up close and personal, you can also go to the Wireshark Sample Capture page and download a sample capture of SSL traffic (along with the key to decrypt the traffic).

The current version of TLS is 1.2 (TLS 1.3 is still in draft) and is covered in RFC 5246. Interestingly enough, there are 10 RFC updates to the protocol, but the RFC itself was not updated. Some of them are extensions to TLS, but RFC 7905 describes the use of the ChaCha stream cipher and Poly1305 authenticator in TLS 1.2 or later. If you look at the POODLE attack and its variants, you'll see that it was mainly an attack on the CBC encryption mode itself. Variant attacks that are aimed at TLS attempt to get the negotiation to "fallback" to SSL 3.0, but there are now variants that attack the specific implementation of TLS that improperly validate the padding. So therefore, there are not flaws in the protocol, but in its specific implementation on servers. And also note that the block ciphers have this issue, but not the stream ciphers (ChaCha is a stream cipher). The only stream cipher previously mentioned in the study guides is RC4 - which is relatively weak. So I guess the hunt is on for a good stream cipher to implement with TLS. Note that none of this is in any of the study materials - but could end up on the test in some form.

TLS is considered to be composed of two layers: The TLS Record Protocol and The TLS Handshake Protocol. "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. Four protocols that use the record protocol are described in this (RFC 5246) document: the handshake protocol, the alert protocol, the change cipher spec protocol, and the application data protocol." [Note that those are the same as the SSL record types.]

The TLS Handshaking Protocols have "three subprotocols that are used to allow peers to agree upon security parameters for the record layer, to authenticate themselves, to instantiate negotiated security parameters, and to report error conditions to each other." These are the Change Cipher Spec Protocol, Alert Protocol and the third one is not specified in the layout of the RFC. I would guess that it is the Application Data Protocol. (This fits in with the SSL record types.) If you look at the RFC, "7. The TLS Handshaking Protocols" is followed by "7.1 Change Cipher Spec Protocol," and then "7.2 Alert Protocol." The expected 7.3 is actually an overview of the Handshake Protocol. This means the third is either a circular loop or was forgotten. Further down, you will find "10. Application Data Protocol" which is probably the third. So this makes it a bit difficult to firmly construct or fit into a neat table. But if you think about the questions you see, you may be able to deduce some type of delineation that they're trying to make. Errors are under the Alert Protocol. Most of the negotiation messages are under the Handshake Protocol. I can imagine a question where you have to choose 4 and there are 5 or 6 recognizable answers. (Like with the SSL question above.)

There are two more items to mention about TLS. The first is to point out that this is all TCP-based. You are setting up a secure connection between two entities. TCP is connection-oriented. The second is to point out that Digital Certificates are used for authentication. Authentication can be made optional, but normally at least one of the peers is authenticated. [Think of the web browser implementation.] The specific implementation can authenticate one or both of the peers. One instance would be a secure web site - where the server presents its digital certificate to demonstrate its authenticity to the person using the site. Another example would be a secure web-based application - where the server would present its digital certificate and the user would present a digital certificate so the server can authenticate an authorized user.

DTLS - Datagram Transport Layer Security is covered by RFC 6347. It also has two updates that relate to preventing fallback to SSL 3.0 and ChaCha20-Poly1305 Cipher Suites. It is based on TLS and is used for protection of UDP (connectionless) datagrams. If you read section 3 - Overview of DTLS, you get a sense of the problem they are trying to solve with this protocol. TLS breaks when trying to use it with UDP applications. [UDP is commonly used for voice and video.] Ciphers that are based on sequential packets break when a packet is lost or out of order. So for DTLS, stream ciphers are banned. [Note the issue with block ciphers above regarding POODLE, and also the update with ChaCha.] The message ordering issue is resolved by adding explicit sequence numbers. Note that DTLS was intentionally made to be as close to TLS as possible - just adding tweaks to make it play well with UDP.

And with this, I am marking these topics as done. If you are at this level of understanding about SSL/TLS/DTLS, you're probably good for any of these questions. If you are having trouble understanding or remembering any of this, I highly recommend downloading some of the sample capture files from the Wireshark site (listed above). Once you start poring through packets and see the messages in action, you get more of a feel for the structure of this and see its implementation.