forting to have the key parts of the book reviewed by those who either designed the stan- dards or broke them and by those who wrote the programs I talk about. Kenny Paterson was tremendously helpful with his thorough review of the protocol attacks chapter,which is easily the longest and the most complicated part of the book.I suspect he gave me the same treatment his students get,and my writing is much better because of it.It took me an entire week to update the chapter in response to Kenny's comments Benne de Weger reviewed the chapters about cryptography and the PKI attacks.Nasko Os- kov reviewed the key chapters about the protocol and Microsoft's implementation.Rick An- drews and his colleagues from Symantec helped with the chapters on PKI attacks and browser issues,as did Adam Langley.Marc Stevens wrote to me about PKI attacks and espe- cially about chosen-prefix attacks against MD5 and SHA1.Nadhem AlFardan,Thai Duong and Juliano Rizzo reviewed the protocol attacks chapter and were very helpful answering my questions about their work.llya Grigoriks review of the performance chapter was thor- ough and his comments very useful.Jakob Schlyter reviewed the chapter about advanced topics (HSTS and CSP),with a special focus on DANE.Rich Bowen and Jeff Trawick re- viewed the Apache chapter;Jeff even fixed some things in Apache related to TLS and made me work harder to keep up with the changes.Xuelei Fan and Erik Costlow from Oracle re- viewed the Java chapter,as did Mark Thomas,William Sargent,and Jim Manico.Andrei Popov and Ryan Hurst reviewed the Microsoft chapter.Maxim Dounin was always quick to respond to my questions about Nginx and reviewed the chapter on it. Vincent Bernat's microbenchmarking tool was very useful to me when I was writing the performance chapter. Eric Lawrence sent me hundreds of notes and questions.I never thought I would see a re- that thorough.Eric is every author dream reviewer,and Iam incredibly ato Also,a big thanks to my readers who sent me great feedback:Pascal Cuoq,Joost van Dijk, Daniel van Eeden,Dr Stephen N.Henson,Brian Howson,Rainer Jung,Brian King,Hendrik Klinge,Olivier Levillain,Colm MacCarthaigh,Dave Novick,Pascal Messerli,and Christian Sage. My special thanks goes to my copyeditor,Melinda Rankin,who was always quick to re- spond with her edits and adapted to my DocBook-based workflow.I'd be amiss not to men- tion my employer,Qualys,for supporting my writing and my work on SSL Labs. Preface
forting to have the key parts of the book reviewed by those who either designed the standards or broke them and by those who wrote the programs I talk about. Kenny Paterson was tremendously helpful with his thorough review of the protocol attacks chapter, which is easily the longest and the most complicated part of the book. I suspect he gave me the same treatment his students get, and my writing is much better because of it. It took me an entire week to update the chapter in response to Kenny’s comments. Benne de Weger reviewed the chapters about cryptography and the PKI attacks. Nasko Oskov reviewed the key chapters about the protocol and Microsoft’s implementation. Rick Andrews and his colleagues from Symantec helped with the chapters on PKI attacks and browser issues, as did Adam Langley. Marc Stevens wrote to me about PKI attacks and especially about chosen-prefix attacks against MD5 and SHA1. Nadhem AlFardan, ai Duong, and Juliano Rizzo reviewed the protocol attacks chapter and were very helpful answering my questions about their work. Ilya Grigorik’s review of the performance chapter was thorough and his comments very useful. Jakob Schlyter reviewed the chapter about advanced topics (HSTS and CSP), with a special focus on DANE. Rich Bowen and Jeff Trawick reviewed the Apache chapter; Jeff even fixed some things in Apache related to TLS and made me work harder to keep up with the changes. Xuelei Fan and Erik Costlow from Oracle reviewed the Java chapter, as did Mark omas, William Sargent, and Jim Manico. Andrei Popov and Ryan Hurst reviewed the Microsoft chapter. Maxim Dounin was always quick to respond to my questions about Nginx and reviewed the chapter on it. Vincent Bernat’s microbenchmarking tool was very useful to me when I was writing the performance chapter. Eric Lawrence sent me hundreds of notes and questions. I never thought I would see a review that thorough. Eric is every author’s dream reviewer, and I am incredibly grateful for his attention. Also, a big thanks to my readers who sent me great feedback: Pascal Cuoq, Joost van Dijk, Daniël van Eeden, Dr Stephen N. Henson, Brian Howson, Rainer Jung, Brian King, Hendrik Klinge, Olivier Levillain, Colm MacCárthaigh, Dave Novick, Pascal Messerli, and Christian Sage. My special thanks goes to my copyeditor, Melinda Rankin, who was always quick to respond with her edits and adapted to my DocBook-based workow. I’d be amiss not to mention my employer, Qualys, for supporting my writing and my work on SSL Labs. xxii Preface
1 SSL.TLS,and Cryptography We live in an increasingly connected world.During the last decade of the 20th century the Internet rose to popularity and forever changed how we live our lives.Today we rely on our phones and computers to communicate,buy goods,pay bills,travel,work,and soon Many of us,with always-on devices in our pockets,don't connect to the Internet,we are the Inter- net.There are already more phones than people.The number of smart phones is measured in billions and increases at a fast pace.In the meantime,plans are under way to connect al sorts of devices to the same network.Clearly,we're just getting started. All the devices connected to the Internet have one thing in common-they rely on the pro- tocols called SSL (Secure Socket Layer)and TLS(Transport Layer Security)to protect the in- formation in transit. Transport Layer Security When the Internet was originally designed,little thought was given to security.As a result, the core communication protocols are inherently insecure and rely on the honest behavior of all involved parties.That might have worked back in the day,when the Internet consisted of a small number of nodes-mostly universities-but falls apart completely today when ev- eryone is online SSL and TLS are cryptographic protocols designed to provide secure communication over insecure infrastructure.What this means is that,if these protocols are properly deployed, you can open a communication channel to an arbitrary service on the Internet,be reason ably sure that you're talking to the correct server,and exchange information safe in knowing that your data won't fall into someone else's hands and that it will be received intact.These protocols protect the communication link or transport layer,which is where the name TLS comes from. Security is not the only goal of TLS.It actually has four main goals,listed here in the order of priority:
1 SSL, TLS, and Cryptography We live in an increasingly connected world. During the last decade of the 20th century the Internet rose to popularity and forever changed how we live our lives. Today we rely on our phones and computers to communicate, buy goods, pay bills, travel, work, and so on. Many of us, with always-on devices in our pockets, don’t connect to the Internet, we are the Internet. ere are already more phones than people. e number of smart phones is measured in billions and increases at a fast pace. In the meantime, plans are under way to connect all sorts of devices to the same network. Clearly, we’re just getting started. All the devices connected to the Internet have one thing in common—they rely on the protocols called SSL (Secure Socket Layer) and TLS (Transport Layer Security) to protect the information in transit. Transport Layer Security When the Internet was originally designed, little thought was given to security. As a result, the core communication protocols are inherently insecure and rely on the honest behavior of all involved parties. at might have worked back in the day, when the Internet consisted of a small number of nodes—mostly universities—but falls apart completely today when everyone is online. SSL and TLS are cryptographic protocols designed to provide secure communication over insecure infrastructure. What this means is that, if these protocols are properly deployed, you can open a communication channel to an arbitrary service on the Internet, be reasonably sure that you’re talking to the correct server, and exchange information safe in knowing that your data won’t fall into someone else’s hands and that it will be received intact. ese protocols protect the communication link or transport layer, which is where the name TLS comes from. Security is not the only goal of TLS. It actually has four main goals, listed here in the order of priority: 1
Cryptographic security This is the main issue:enable secure communication between any two parties who wish to exchange information Interoperability Independent programmers should be able to develop programs and libraries that are able to communicate with one another using common cryptographic parameters. Extensibility As you will soon see,TLS is effectively a framework for the development and deploy- ment of cryptographic protocols.Its important goal is to be independent of the actual cryptographic primitives(e.g.,ciphers and hashing functions)used,allowing migra- tion from one primitive to another without needing to create new protocols Efficiency The final goal is to achieve all of the previous goals at an acceptable performance cost. reducing costly cryptographic operations down to the minimum and providing a ses- sion caching scheme to avoid them on subsequent connections. Networking Layers At its core,the Internet is built on top of IP and TCP protocols,which are used to package data into small packets for transport.As these packets travel thousands of miles across the world,they cross many computer systems(called hops)in many countries.Because the core protocols don't provide any security by themselves,anyone with access to the communica tion links can gain full access to the data as well as change the traffic without detection. IP and TCP aren't the only vulnerable protocols.There's a range of other protocols that are used for routing-helping computers find other computers on the network.DNS and BGP are two such protocols.They,too,are insecure and can be hijacked in a variety of ways.If that happens,a connection intended for one computer might be answered by the attacker instead. When encryption is deployed,the attacker might be able to gain access to the encrypted da- ta,but she wouldn't be able to decrypt it or modify it.To prevent impersonation attacks,SSL and TLS rely on another important technology called PKI(public-key infrastructure),which ensures that the traffic is sent to the correct recipient. To understand where SSL and TLS fit,were going to take a look at the Open Systems Inter- connection (OSI)model,which is a conceptional model that can be used to discuss network communication.In short,all functionality is mapped into seven layers.The bottom layer is the closest to the physical communication link;subsequent layers build on top of one anoth er and provide higher levels of abstraction.At the top is the application layer,which carries application data 2 Chapter 1:SSL,TLS,and Cryptography
Cryptographic security is is the main issue: enable secure communication between any two parties who wish to exchange information. Interoperability Independent programmers should be able to develop programs and libraries that are able to communicate with one another using common cryptographic parameters. Extensibility As you will soon see, TLS is effectively a framework for the development and deployment of cryptographic protocols. Its important goal is to be independent of the actual cryptographic primitives (e.g., ciphers and hashing functions) used, allowing migration from one primitive to another without needing to create new protocols. Efficiency e final goal is to achieve all of the previous goals at an acceptable performance cost, reducing costly cryptographic operations down to the minimum and providing a session caching scheme to avoid them on subsequent connections. Networking Layers At its core, the Internet is built on top of IP and TCP protocols, which are used to package data into small packets for transport. As these packets travel thousands of miles across the world, they cross many computer systems (called hops) in many countries. Because the core protocols don’t provide any security by themselves, anyone with access to the communication links can gain full access to the data as well as change the traffic without detection. IP and TCP aren’t the only vulnerable protocols. ere’s a range of other protocols that are used for routing—helping computers find other computers on the network. DNS and BGP are two such protocols. ey, too, are insecure and can be hijacked in a variety of ways. If that happens, a connection intended for one computer might be answered by the attacker instead. When encryption is deployed, the attacker might be able to gain access to the encrypted data, but she wouldn’t be able to decrypt it or modify it. To prevent impersonation attacks, SSL and TLS rely on another important technology called PKI (public-key infrastructure), which ensures that the traffic is sent to the correct recipient. To understand where SSL and TLS fit, we’re going to take a look at the Open Systems Interconnection (OSI) model, which is a conceptional model that can be used to discuss network communication. In short, all functionality is mapped into seven layers. e bottom layer is the closest to the physical communication link; subsequent layers build on top of one another and provide higher levels of abstraction. At the top is the application layer, which carries application data. 2 Chapter 1: SSL, TLS, and Cryptography
Note posbtoneatlyorreal-life model For example,SPDY and HTTP/2 could go into the session layer because they deal with connection management,but they operate after encryption.Layers from five on- wards are often fuzzy. Table 1.1.OSI model layers OSI Layer Descrintion Example protocols 1 Application Application data HTTP.SMTP.IMAP 6 Presentation SSITIS 5 Session Management of multiple connections Transport Reliable delivery of packetsd strems TCP,UDP 3 Network Routing and delivery of datagrams between network nodes IP.IPSec 2 Data link Reliable(LAN) Ethernet Physical Direct physical datatin(cables) CAT5 Arranging communication in this way provides clean separation of concerns;protocols don't need to worry about the functionality implemented by lower layers.Further,protocols at different layers can be added and removed;a protocol at a lower layer can be used for many protocols from higher levels. SSL and TLS are a great example of how this principle works in practice.They sit above TCP but below higher-level protocols such as HTTP.When encryption is not necessary,we can remove TLS from our model,but that doesn't affect the higher-level protocols,which con- tinue to work directly with TCP.When you do want encryption,you can use it to encrypt HTTP,but also any other TCP protocol,for example SMTB IMAP and so on. Protocol History SSLprotocol was developed at Netscape,back when Netscape Navigator rued the Internet. The first version of the protocol never saw the light of day,but the next-version 2-was released in November 1994.The first deployment was in Netscape Navigator 1.1,which was released in March 1995. Developed with little to no consultation with security experts outside Netscape,SSL2 ended up being a poor protocol with serious weaknesses.This forced Netscape to work on SSL 3, which was released in late 1995.Despite sharing the name with earlier protocol versions, SSL 3 was a brand new protocol design that established the design we know today. For a much more detailed history of theearly years of the SSLptecommend Eric Rescorla's bookSSLand TLS DesigningndBlding Secure Systems (Addison-Wesley,2001).pages47-51. Prot History
Note It’s not always possible to neatly organize real-life protocols into the OSI model. For example, SPDY and HTTP/2 could go into the session layer because they deal with connection management, but they operate after encryption. Layers from five onwards are often fuzzy. Table 1.1. OSI model layers # OSI Layer Description Example protocols 7 Application Application data HTTP, SMTP, IMAP 6 Presentation Data representation, conversion, encryption SSL/TLS 5 Session Management of multiple connections - 4 Transport Reliable delivery of packets and streams TCP, UDP 3 Network Routing and delivery of datagrams between network nodes IP, IPSec 2 Data link Reliable local data connection (LAN) Ethernet 1 Physical Direct physical data connection (cables) CAT5 Arranging communication in this way provides clean separation of concerns; protocols don’t need to worry about the functionality implemented by lower layers. Further, protocols at different layers can be added and removed; a protocol at a lower layer can be used for many protocols from higher levels. SSL and TLS are a great example of how this principle works in practice. ey sit above TCP but below higher-level protocols such as HTTP. When encryption is not necessary, we can remove TLS from our model, but that doesn’t affect the higher-level protocols, which continue to work directly with TCP. When you do want encryption, you can use it to encrypt HTTP, but also any other TCP protocol, for example SMTP, IMAP and so on. Protocol History SSL protocol was developed at Netscape, back when Netscape Navigator ruled the Internet.1 e first version of the protocol never saw the light of day, but the next—version 2—was released in November 1994. e first deployment was in Netscape Navigator 1.1, which was released in March 1995. Developed with little to no consultation with security experts outside Netscape, SSL 2 ended up being a poor protocol with serious weaknesses. is forced Netscape to work on SSL 3, which was released in late 1995. Despite sharing the name with earlier protocol versions, SSL 3 was a brand new protocol design that established the design we know today. 1 For a much more detailed history of the early years of the SSL protocol, I recommend Eric Rescorla’s book SSL and TLS: Designing and Building Secure Systems (Addison-Wesley, 2001), pages 47–51. Protocol History 3
In May 1996,the TLS working group was formed to migrate SSL from Netscape to IETE2 The process was painfully slow because of the political fights between Microsoft and Netscape,a consequence of the larger fight to dominate the Web.TLS 1.0 was finally re leased in January 1999,as RFC 2246.Although the differences from SSL 3 were not big,the name was changed to please Microsoft.3 The next version,TLS 1.1,wasn't released until April 2006 and contained essentially only security fixes.However,a major change to the protocol was incorporation of TLS extensions, which were released a couple of years earlier,in June 2003. TLS 1.2 was released in August 2008.It added support for authenticated encryption and generally removed all hard-coded security primitives from the specification,making the protocol fully flexible. The next protocol version,which is currently in development,is shaping to be a major revi- sion aimed at simplifying the design,removing many of the weaker and less desirable fea- tures,and improving performance.You can follow the discussions on the TLS working group mailing list. Cryptography Cryptography is the science and art of secure communication.Although we associate en cryption with the modern age,we've actually been using cryptography for thousands of years.The first mention of a,an encryption too dates to the seventh century BC.s Cryptography as we know it today was largely born in the twentieth century and for mili tary use.Now it's part of our everyday lives. When cryptography is correctly deployed,it addresses the three core requirements of secu rity:keeping secrets(confidentiality),verifying identities (authenticity),and ensuring safe transport(integrity). In the rest of this chapter,I will discuss the basic building blocks of cryptography,with the goal of showing where additional security comes from.I will also discuss how cryptography is commonly attacked.Cryptography is a very diverse field and has a strong basis in mathe- matics,but I will keep my overview at a high level,with the aim of giving you a foundation that will enable you to follow the discussion in the rest of the text.Elsewhere in the book, where the topic demands.I will discuss some parts of cryptography in more detail. 2TLS Working Group (IETF.retrieved 23 June 2014) nges in the Browser Wars (Tm Dierks,23 May 21) Chapter 1:SSL,TLS,and Cryptography
In May 1996, the TLS working group was formed to migrate SSL from Netscape to IETF.2 e process was painfully slow because of the political fights between Microsoft and Netscape, a consequence of the larger fight to dominate the Web. TLS 1.0 was finally released in January 1999, as RFC 2246. Although the differences from SSL 3 were not big, the name was changed to please Microsoft.3 e next version, TLS 1.1, wasn’t released until April 2006 and contained essentially only security fixes. However, a major change to the protocol was incorporation of TLS extensions, which were released a couple of years earlier, in June 2003. TLS 1.2 was released in August 2008. It added support for authenticated encryption and generally removed all hard-coded security primitives from the specification, making the protocol fully exible. e next protocol version, which is currently in development, is shaping to be a major revision aimed at simplifying the design, removing many of the weaker and less desirable features, and improving performance. You can follow the discussions on the TLS working group mailing list.4 Cryptography Cryptography is the science and art of secure communication. Although we associate encryption with the modern age, we’ve actually been using cryptography for thousands of years. e first mention of a scytale, an encryption tool, dates to the seventh century BC.5 Cryptography as we know it today was largely born in the twentieth century and for military use. Now it’s part of our everyday lives. When cryptography is correctly deployed, it addresses the three core requirements of security: keeping secrets (confidentiality), verifying identities (authenticity), and ensuring safe transport (integrity). In the rest of this chapter, I will discuss the basic building blocks of cryptography, with the goal of showing where additional security comes from. I will also discuss how cryptography is commonly attacked. Cryptography is a very diverse field and has a strong basis in mathematics, but I will keep my overview at a high level, with the aim of giving you a foundation that will enable you to follow the discussion in the rest of the text. Elsewhere in the book, where the topic demands, I will discuss some parts of cryptography in more detail. 2 TLS Working Group (IETF, retrieved 23 June 2014) 3 Security Standards and Name Changes in the Browser Wars (Tim Dierks, 23 May 2014) 4 TLS working group mailing list archives (IETF, retrieved 19 July 2014) 5 Scytale (Wikipedia, retrieved 5 June 2014) 4 Chapter 1: SSL, TLS, and Cryptography