SSL and TLS. Theory and Practice

284 Pages·2016·1.713 MB·English

by  Rolf Oppliger

SSL and TLS
Theory and Practice
Second Edition
Rolf Oppliger
ISBN 13: 978-1-60807-998-8
© 2016 ARTECH HOUSE
685 Canton Street
Norwood, MA 02062
Contents
Preface xi
Chapter 1 Introduction 1
1.1 InformationandNetworkSecurity 1
1.1.1 SecurityServices 3
1.1.2 SecurityMechanisms 7
1.2 TransportLayerSecurity 11
1.3 FinalRemarks 18
References 19
Chapter 2 SSLProtocol 21
2.1 Introduction 21
2.2 Protocols 31
2.2.1 SSLRecordProtocol 31
2.2.2 SSLHandshakeProtocol 46
2.2.3 SSLChangeCipherSpecProtocol 70
2.2.4 SSLAlertProtocol 71
2.2.5 SSLApplicationDataProtocol 73
2.3 ProtocolExecutionTranscript 74
2.4 SecurityAnalysesandAttacks 79
2.5 FinalRemarks 87
References 88
Chapter 3 TLSProtocol 91
3.1 Introduction 91
3.1.1 TLSPRF 94
3.1.2 GenerationofKeyingMaterial 96
3.2 TLS1.0 99
3.2.1 CipherSuites 99
3.2.2 CertificateManagement 102
3.2.3 AlertMessages 104
3.2.4 OtherDifferences 105
3.3 TLS1.1 106
3.3.1 CryptographicSubtleties 107
3.3.2 CipherSuites 113
3.3.3 CertificateManagement 115
3.3.4 AlertMessages 115
3.3.5 OtherDifferences 116
3.4 TLS1.2 116
3.4.1 TLSExtensions 116
3.4.2 CipherSuites 135
3.4.3 CertificateManagement 138
3.4.4 AlertMessages 138
3.4.5 OtherDifferences 139
3.5 TLS1.3 139
3.5.1 CipherSuites 142
3.5.2 CertificateManagement 143
3.5.3 AlertMessages 143
3.5.4 OtherDifferences 144
3.6 HSTS 144
3.7 ProtocolExecutionTranscript 147
3.8 SecurityAnalysesandAttacks 151
3.8.1 RenegotiationAttack 152
3.8.2 Compression-RelatedAttacks 158
3.8.3 MoreRecentPaddingOracleAttacks 162
3.8.4 KeyExchangeDowngradeAttacks 168
3.8.5 FREAK 168
3.8.6 Logjam 169
3.9 FinalRemarks 170
References 171
Chapter 4 DTLSProtocol 177
4.1 Introduction 177
4.2 BasicPropertiesandDistinguishingFeatures 180
4.2.1 RecordProtocol 181
4.2.2 HandshakeProtocol 183
4.3 SecurityAnalysis 187
4.4 FinalRemarks 189
References 189
Chapter 5 FirewallTraversal 191
5.1 Introduction 191
5.2 SSL/TLSTunneling 194
5.3 SSL/TLSProxying 197
5.4 FinalRemarks 199
References 200
Chapter 6 PublicKeyCertificatesandInternetPKI 201
6.1 Introduction 201
6.2 X.509Certificates 206
6.2.1 CertificateFormat 207
6.2.2 HierarchicalTrustModel 209
6.3 ServerCertificates 212
6.4 ClientCertificates 216
6.5 ProblemsandPitfalls 217
6.6 NewApproaches 222
6.7 FinalRemarks 228
References 229
Chapter 7 ConcludingRemarks 233
References 235
Appendix ARegisteredTLSCipherSuites 237
Appendix BPaddingOracleAttacks 245
B.1 BleichenbacherAttack 247
B.2 VaudenayAttack 251
References 260
Appendix CAbbreviationsandAcronyms 263
AbouttheAuthor 271
Index 273
Preface
Intheory,theoryandpracticearethesame.
Inpractice,theyarenot.
—AlbertEinstein
Termslikeelectroniccommerce(e-commerce),electronicbusiness(e-business),and
electronic government (e-government) are omnipresent today. When people use
theseterms, theyoftenrefertostringentsecurityrequirementsthatmustbemetin
onewayoranother.Iftheywanttomanifestthattheyaretech-savvy,thentheybring
in acronymslike SSL or TLS. Since SSL standsfor secure sockets layer and TLS
standsfortransportlayersecurity,itseemsthataddingSSLorTLStoapplications
automaticallymakesthem secure and magicallysolvesall securityproblems.This
is arguablynot the case and largely exaggeratesthe role SSL/TLS can play in the
securityarena.
ButSSL/TLSisstillthemostwidelyusedandmostimportanttechnologyto
secure e-∗ applicationsor certain aspects thereof. This is certainly the case for all
applicationsontheWorldWideWeb(WWW)basedonthehypertexttransferproto-
col(HTTP),butitisincreasinglyalsotrueformanyotherInternetapplications,such
aselectronicmail(e-mail),instantmessaging,filetransfer,terminalaccess,Internet
banking,moneytransfer,electronicvoting(e-voting),andonlinegaming.Manyof
theseapplicationsandrespectiveapplicationprotocolsarenowadaysroutinelylay-
ered on top of SSL and TLS protocols to provide some basic security services to
theirusers.
Considering the wide deploymentof the SSL/TLS protocols, it is important
toteache-∗applicationdesignersanddevelopersaboutthefundamentalprinciples
and the rationale behind the various versions of the protocols. Simply invoking
security software libraries and respective function calls is not enough to design
and develop secure applications.1 In fact, it is fairly common today to invoke
such libraries and function calls from otherwise exploitable code. The resulting
applicationisnotgoingtobesecure—whetherSSL/TLSisinplaceornot.Against
thisbackground,secureprogrammingandsecuresoftwaredevelopmenttechniques
areoftheutmostimportancewhenitcomestobuildingsecureapplications.Also,a
thoroughunderstandingofasecuritytechnologyisrequiredtocorrectlyapplyitand
properly complement it with other security technologies. This rule of thumb also
appliestoSSL/TLS.ItisnecessarytofullyunderstandwhattheSSL/TLSprotocols
candoandwhattheycannotdoinordertoapplythemcorrectly.Otherwise,mistakes
and omissions are likely to occur and to hurt badly. The SSL/TLS protocols are
not a panacea. They enable applications to be only as secure as the underlying
infrastructuralcomponents, such as the computer systems and networks in use. If
these components are vulnerable and susceptible to attacks, then the security the
SSL/TLSprotocolsmayprovideisquestionableorevenillusive.
When I started to compile a teaching module about SSL/TLS more than 10
years ago, I was surprised to learn that the few books that were available then
either addressed the technology only superficially or—maybe worse—were out-
of-date. This was particularly true for the two reference books used in the field
[1, 2]. They both appeared in 2000—which was almost a decade ago. Against
this background,I decided to take my lecture notes and compile a new book that
would not only address the fundamentalprinciples of the SSL/TLS protocols, but
would also try to explain the rationale behind their current designs. The resulting
book appeared in 2009. The triumphant success of SSL/TLS and many recent
developments have made it necessary to update the book and publish a second
edition sooner than originallyanticipated. This seems to be the price to pay when
addressing a hot and fastly evolving field: Books become outdated even sooner
than is normally the case. So I have taken the opportunity to update the book
and to bring it in line with some of the more recent cryptanalytical results and
developments.Someoftheseresultswereknownwhenthefirsteditionofthebook
1 Sometimesthelibrariesthemselvescontainbugsthatallowadversaries toattackthesystemsthat
employ them.In2014,forexample, itwas revealed thattheSSL/TLSimplementation ofApple
iOScontainedaseriousbugthatwaslaternamedthe“doublegotofail”bug(becauseitwascaused
byagotofailstatementthatwaserroneouslywrittentwice)andthattheGnuTLSimplementation
containedasimilarbugnamed“GnuTLSbug.”Thebugsweresimilarinthesensethattheyboth
allowed invalid public key certificates to pass certificate validation checks, and hence that an
adversarycouldusesuchcertificates tomountaman-in-the-middle (MITM)attack.Maybemost
importantly, it was revealed in the same year that some elder versions of the OpenSSL library
contained a very severe bug in the implementation of the Heartbeat extension of the (D)TLS
protocol(s). As further addressed in Section 3.8, this bug allowed an adversary to read out the
servermemory,possiblycompromisingcryptographickeysstoredtherein.Thebugbecameknown
asHeartbleed,anditcastedadamninglightonthesecurityofOpenSSL.
went to press. However, they were not properly addressed, because there was no
evidencethat the underlyingtheoreticalvulnerabilitiescould actually be exploited
inpractice.Thishaschangedfundamentally,andtermslikeBEAST,CRIME,TIME,
BREACH,POODLE,FREAK,Logjam,andLucky13havemadealotofheadlines
and frightened both application developersand users. Keeping the old saying that
“attacksalwaysgetbetter;theynevergetworse”inmind,onecanreasonablyexpect
manyinteresting attacks to be mountedin the future.2 The situation remainsrisky
andscary.
More recently, a book on SSL/TLS that is more in line with this book has
appeared [3]. It also addresses the fundamentals of SSL/TLS and the abovemen-
tionedattacks.Unlikethisbook,however,majorpartsof[3]addresscomplementary
topics (that are not directly related to security), such as implementation, deploy-
ment,performanceoptimization,andconfigurationissues—sometimesevenrelated
tospecificproducts.Forthereasonsdiscussedbelow,SSL/TLS:TheoryandPractice,
SecondEdition,takesadifferentapproachanddelvesintoneitherimplementationis-
suesnorconfigurationdetailsofparticularimplementations.Also,itaddressessome
practicallyimportanttopicsthatareentirelyneglectedinotherbooksincluding[3],
suchasTLSextensions,TLSversion1.3,anddatagramTLS(DTLS),anddiscusses
cryptanalyticalattacks and techniquesto protect against them and mitigate the re-
spectiverisks.
In additionto providinga basic introductionand discussion of the SSL/TLS
protocols,anotherimportantgoalofthissecondeditionistoprovideenoughback-
groundinformationtounderstand,discuss,andputintoperspectivethelatestcrypt-
analytical attacks and attack tools. This goal is ambitious, because the attacks are
notatallsimpleandstraightforward.Instead,theyrequirequitealotofbackground
knowledgeincryptography.ThisisoneofthereasonsIhavechangedtheoutlineof
the book a little bit: Instead of providinga cryptographyprimer and starting from
scratch,Iassumethatreadersalreadyhavesomebasicknowledgeaboutcryptogra-
phyandstartfromthere.Thus,readerswhowanttoseriouslydelveintothesecurity
of SSL/TLS should acquire this knowledge first. Fortunately, they can use many
booksforthispurpose,including[4].
Exceptfortheomissionofthecryptographyprimer,Ihavetriedtostayasclose
aspossibletotheoriginaloutlineofthefirsteditionofthebook.Thiseditionisagain
intendedforanyonewhowantstogetadeepunderstandingoftheSSL/TLSproto-
cols and their properuse—be they theorists or practitioners. As mentionedabove,
implementation issues and respective details are not addressed or only addressed
superficially. There are so many implementations of the SSL/TLS protocols, both
freelyandcommerciallyavailable,thatitmakesnosensetoaddresstheminabook.
2 Asanexampleofsuchattacks,youmayrefertotheblogentry“ThePOODLEhasfriends,”which
isavailableathttps://vivaldi.net/en-US/blogs/entry/the-poodle-has-friends.
Theyaremodifiedandupdatedtoofrequently.Themostpopularopen-sourceimple-
mentations are OpenSSL,3 GnuTLS,4 Bouncy Castle,5 and MatrixSSL,6 but there
aremanymore.Someoftheseimplementationsareavailableunderalicensethatis
compatiblewiththeGNUGeneralPublicLicense(GPL),suchasGnuTLS,whereas
the licenses of some other implementations are special and slightly deviate from
the GPL, such as the OpenSSL license. Because this book targets techniciansand
not lawyers, I do not further address the many issues regardingsoftware licenses.
Instead, I emphasize the fact that some open-source implementations have a bad
trackrecordwhenitcomestosecurity(remembertheHeartbleedbugmentionedin
footnote1),andhencetherearealsoafewopen-sourceimplementationsthatforked
fromOpenSSL,suchasLibreSSLfromOpenBSD,7BoringSSLfromGoogle,8and
s2n9 from Amazon.10 More interestingly, there are open source SSL/TLS imple-
mentations that make it possible to perform a formal verification of the resulting
implementation, such as miTLS.11 Furthermore, there are some SSL/TLS imple-
mentationsthataredual-licensed,meaningthattheyareavailableeitherasanopen
source or under a commercial license. Examples include mbed TLS12 (formerly
known as PolarSSL13), wolfSSL14 (formerly known as CyaSSL), and cryptlib.15
In addition,all major software manufacturershave SSL/TLS implementationsand
librariesoftheirownthattheyroutinelyembedintheirproducts.Examplesinclude
SecureChannel(SChannel)fromMicrosoft,SecureTransportfromApple,theJava
SecureSocketExtensions(JSSE) fromOracle,and the Network SecurityServices
(NSS) from Mozilla.16 Due to their origin, these implementations are particularly
widely deployed in the field and hence used by many people in daily life. If you
want to use the SSL/TLS protocolspractically (e.g., to secure an e-∗ application),
then you have to delve into the documentation and technical specification of the
application or development environment that you are currently using. This book
is not a replacement for these documents; it is only aimed at providing the basic
3 http://www.openssl.org.
4 http://www.gnutls.org.
5 http://www.bouncycastle.org.
6 http://www.matrixssl.org.
7 http://www.libressl.org.
8 https://boringssl.googlesource.com/boringssl.
9 Theacronym s2nstands for“signal tonoise,” referring tothe fact thatthe signals generated by
legitimatevisitorsofwebsitesmaybehiddenfromnoisebytheuseofstrongcryptography.
10 https://github.com/awslabs/s2n.
11 http://www.mitls.org.
12 https://tls.mbed.org.
13 https://polarssl.org.
14 http://yassl.com.
15 http://www.cryptlib.com.
16 NotethattheNSSisalsoavailableasopensourceunderaspecialMozillaPublicLicense(MPL).
knowledgeto properlyunderstandthem—you still have to captureand read them.
In the case of OpenSSL, for example, you may use [5] or Chapter 11 of [3] as a
reference.Keepinmind,though,that,duetoHeartbleed,thereputationofOpenSSL
isdiscussedcontroversiallyinthecommunity.Inthecase ofanotherlibraryorde-
velopmentenvironment,youhavetoreadtheoriginaldocumentation.
In addition to cryptography, this book also assumes some basic familiarity
with the TCP/IP protocols and their working principles. Again, this assumption
is reasonable, because anybody not familar with TCP/IP is well-advised to first
get in touch and try to comprehend TCP/IP networking, before moving on to the
SSL/TLSprotocols—onlytryingtounderstandSSL/TLSisnotlikelytobefruitful.
Readers unfamiliar with TCP/IP networking can consult one of the many books
aboutTCP/IP. Among these books, I particularly recommendthe classic booksof
Richard Stevens [6] and Douglas Comer [7], but there are many other (or rather
complementary)booksavailable.
ToproperlyunderstandthecurrentstatusoftheSSL/TLSprotocols,itisuseful
tobefamiliarwiththeInternetstandardizationprocess.Again,thisprocessislikely
tobeexplainedinabookonTCP/IPnetworking.ItisalsoexplainedinRFC2026[8]
andupdatedonawebpagehostedbytheInternetEngineeringTaskForce(IETF).17
For each protocol specified in an RFC document, we are going to say whether it
has beensubmitted to the Internetstandardstrack or specified for experimentalor
informationaluse.Thisdistinctionisimportantandhighlyrelevantinpractice.
When we discuss the practical use of the SSL/TLS protocols, it is quite
helpful to visualize things with a network protocol analyzer, such as Wireshark18
or any other software tool that provides a similar functionality. Wireshark is a
freelyavailableopen-sourcesoftwaretool.WithregardtoSSL/TLS,itissufficiently
complete, meaningthat it can be used to analyze SSL/TLS-based data exchanges.
We don’t reproduce screenshots in this book, mainly because the graphical user
interfaces(GUIs)oftoolslikeWiresharkarehighlynonlinear,andthecorresponding
screenshotsaredifficulttoreadandinterpretifonlysinglescreenshotsareavailable.
WhenweuseWiresharkoutput,weprovideitintextualform.Thisisvisuallyless
stimulating,butgenerallymoreappropriateandthereforemoreusefulinpractice.
SSL/TLS:TheoryandPractice,SecondEdition,isorganizedandstructuredin
sevenchapters,describedasfollows.
• Chapter1,Introduction,preparesthegroundforthetopicofthisbookandpro-
videsthe fundamentalsandbasicprinciplesthatarenecessarytounderstand
theSSL/TLSprotocolsproperly.
17 https://www.ietf.org/about/standards-process.html.
18 http://www.wireshark.org.