SSL AND TLS THEORY AND PRACTICE, INFORMATION SECURITY AND PRIVACY SERIES 4TH EDITION BY ROFL OPPLINGER

Document Content and Description Below

SSL AND TLS THEORY AND PRACTICE, INFORMATION SECURITY AND PRIVACY SERIES 4TH EDITION BY ROFL OPPLINGER Contents Foreword xi Preface xv Acknowledgments xxi Chapter 1 Introduction 1 1.1 O... SI Security Architecture 1 1.1.1 Security Services 4 1.1.2 Security Mechanisms 8 1.2 Security Definition 11 1.3 Final Remarks 14 References 15 Chapter 2 Cryptography Primer 17 2.1 Introduction 17 2.1.1 Preliminary Remarks 17 2.1.2 Cryptographic Systems 19 2.1.3 Classes of Cryptographic Systems 21 2.1.4 Secure Cryptosystems 22 2.1.5 Historical Background Information 24 2.1.6 Legal Situation 26 2.2 Cryptosystems Overview 28 2.2.1 Unkeyed Cryptosystems 28 2.2.2 Secret Key Cryptosystems 35 2.2.3 Public Key Cryptosystems 45 2.3 Final Remarks 59 References 60 Chapter 3 Transport Layer Security 65 3.1 Introduction 65 vii viii SSL and TLS: Theory and Practice 3.2 Protocol Evolution 68 3.3 Final Remarks 73 References 73 Chapter 4 SSL Protocol 75 4.1 Introduction 75 4.2 Protocols 87 4.2.1 SSL Record Protocol 87 4.2.2 SSL Handshake Protocol 94 4.2.3 SSL Change Cipher Spec Protocol 117 4.2.4 SSL Alert Protocol 118 4.2.5 SSL Application Data Protocol 120 4.3 Traffic Analysis of an SSL Session 121 4.4 Security Analysis 125 4.5 Final Remarks 129 References 130 Chapter 5 TLS Protocol 133 5.1 Introduction 133 5.1.1 TLS PRF 136 5.1.2 Generation of Keying Material 139 5.2 TLS 1.0 141 5.2.1 Cipher Suites 141 5.2.2 Certificate Management 144 5.2.3 Alert Messages 145 5.2.4 Other Differences 146 5.3 TLS 1.1 147 5.3.1 Preliminary Remarks 147 5.3.2 Cipher Suites 149 5.3.3 Certificate Management 150 5.3.4 Alert Messages 151 5.3.5 Other Differences 151 5.4 TLS 1.2 152 5.4.1 TLS Extensions 153 5.4.2 Cipher Suites 168 5.4.3 Certificate Management 173 5.4.4 Alert Messages 173 5.4.5 Other Differences 174 5.5 Traffic Analysis of a TLS Session 174 5.6 Security Analysis 178 Contents ix 5.7 Final Remarks 178 References 179 Chapter 6 DTLS Protocol 183 6.1 Introduction 183 6.2 DTLS 1.0 186 6.2.1 Record Protocol 187 6.2.2 Handshake Protocol 190 6.3 DTLS 1.2 194 6.4 Security Analysis 195 6.5 Final Remarks 195 References 196 Chapter 7 Firewall Traversal 199 7.1 Introduction 199 7.2 SSL/TLS Tunneling 202 7.3 SSL/TLS Proxying 205 7.4 Final Remarks 206 References 207 Chapter 8 Public Key Certificates and PKIs 209 8.1 Introduction 209 8.1.1 PGP Certificates 213 8.1.2 X.509 Certificates 215 8.2 Server Certificates 218 8.2.1 Wildcard Certificates 220 8.2.2 International Step-Up and SGC Certificates 220 8.2.3 Extended Validation Certificates 221 8.3 Client Certificates 222 8.4 Final Remarks 223 References 224 Chapter 9 Conclusions and Outlook 227 9.1 Deployment 227 9.2 Research Challenges 230 9.2.1 Performance Optimization 230 9.2.2 Protection Against MITM Attacks 232 9.2.3 Trust Management 235 9.3 Future Developments 235 References 236 SSL and TLS: Theory and Practice Appendix Standardized TLS Cipher Suites 239 Abbreviations and Acronyms 243 About the Author 249 Index 251 Chapter 1 Introduction In this introductory chapter, we start slowly and gradually work towards the topic of the book. More specifically, we provide the fundamentals and basic principles that are necessary for a serious and deep treatment of network security protocols in general, and the SSL/TLS protocols in particular. We start with a generic network security architecture or terminology framework known as the OSI security architec- ture in Section 1.1, introduce a security definition and elaborate on how the SSL/TLS protocols attempt to meet this definition in Section 1.2, and conclude with some final remarks in Section 1.3. 1.1 OSI SECURITY ARCHITECTURE According to the IETF Internet Security Glossary published in RFC 2828 [1], a security architecture refers to “a plan and set of principles that describe (a) the security services that a system is required to provide to meet the needs of its users, (b) the system elements required to implement the services, and (c) the performance levels required in the elements to deal with the threat environment.” As such, a security architecture is always the result of applying principles of systems engineering and addresses issues related to physical security, computer security, communication security, organizational security (e.g., administrative and personnel security), and legal security. This integral approach to security is important; too many systems and applications are built and deployed without having an appropriate security architecture in mind. Following the line of argumentation introduced in [2], it is worthwhile to have a look at the real world to illustrate the importance of having (implemented) an appropriate security architecture. If, for example, we want to build a house, then the first—and often most important—person to talk to is the architect. We hardly 1 know anything about architecture and the art or science of designing and building a house, so we feel comfortable having a professional deal with these issues on our behalves. One of the first things an architect does—either explicitly or implicitly—is a threat and risk analysis. For example, given the fact that most burglars enter a house through the front door, he or she makes sure that the house has a front door with a lock, and that entering the house always requires breaking either the door’s lock or a windowpane. In general, the architect does not design the house with unbreakable windowpanes; unbreakable windowpanes are simply too expensive and impractical for normal houses. If, however, the house were to host a branch bank, then broken windows would be more likely to occur, and the architect would probably suggest to install unbreakable windowpanes (or no windows at all). Also, he or she would consult a security specialist to get a burglar alarm system and a vault. The bottom line is that the threat and risk analysis leads to an architecture that is reasonably secure for a given environment. This type of analysis is omnipresent in daily life; often we don’t even realize that it is going on in the back of our heads. Contrary to the real world, the importance of doing a threat and risk analysis and coming up with an appropriate security architecture is less common and hardly understood in the digital world. Too many companies and organizations try to avoid security architectures and directly go to ad hoc testing (also known as ethical hacking1). They hire external forces that attack and try to break into their systems, networks, or applications. If the forces do not suceed, then the customers assume (or rather hope) that they are secure. If, however, the forces suceed, then the customers assume (or rather know) that they are insecure. In this case, they patch the found vulnerabilities and security holes, and then they hope that they are done, meaning that they have found and eliminated all relevant vulnerabilities and security holes. Against this background, the decision whether a customer is secure or not looks arbitrary and mainly depends on the capabilities of the external forces and the tools they are aware of and have at hand. An interesting point to note is that the real-world analogy of an “ethical hacker” would be an “ethical burglar,” and that we don’t see this profession in the real world. In fact, ex-burglars are seldom hired to break windowpanes or rob houses simply to show that the initiator is vulnerable. We know that we are vulnerable, and hence there is no market for ex-burglars to ethically break into houses. In the real world, we neither trust them nor do we believe in the value of such investigations (if this statement were wrong, then there would be a market for such services in the first place). Why should the digital world be different? In fact, it does not seem to be different, and breaking into computer systems and networks is always possible—it 1 One commonly cited difference between an ethical hacker and an adversary is that the former operates with the knowledge, authorization, and consent obtained in advance, whereas the latter operates without these features. is just a question of time, talent, and expenditure. Another point to keep in mind and consider with care when it comes to ethical hacking is that such investigations mainly address threats from the outside. This is not particularly useful, as most statistics reveal the fact that many IT systems and networks are routinely attacked from the inside. This means that insiders should also be considered to be part of the threats model. In the digital world, we need a clear understanding of what we are going to design and implement, what adversaries we should keep in mind and protect against, what resources (in terms of time and computational power) these adversaries typically have, what attack strategies are most likely to occur, what the implications are if an adversary succeeds, what reactions are planned, and so on. All of these considerations should be made in a comprehensive threat and risk analysis that is backed with a security audit. Based on this analysis and audit, a comprehensive security architecture must be defined and documented. Keep in mind that the security architecture is specific and situational, and that there is no such thing as a universally applicable security architecture. In an attempt to extend the field of application of the Open Systems Inter- connection (OSI) basic reference model, the Joint Technical Committee 1 (JTC1) of the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) appended a security architecture as part two of ISO/IEC 7498 in 1989 [3]. Since its publication, the OSI security architecture has turned out to be a primary reference for network security professionals working in the field. In 1991, the Telecommunication Standardization Sector of the International Telecommunication Union (ITU), also known as ITU-T, adopted the OSI security architecture in recommendation X.800 [4]. Also in the early 1990s, the Privacy and Security Research Group (PSRG) of the Internet Research Task Force (IRTF2) pre- liminarly adapted the OSI security architecture in a corresponding Internet security architecture published as an Internet-Draft.3 In essence, ISO/IEC 7498-2, ITU-T X.800, and the Internet security architecture draft all describe the same security architecture, and in this book we use the term OSI security architecture to refer to all of them. Contrary to the OSI basic reference model, the OSI security architecture is in widespread use today—at least for referential purposes. In essence, the OSI security architecture provides a general description of security services and related security mechanisms and discusses their interrelation- ships. It also shows how the security services map onto a given network architecture 2 The IRTF is a sister group to the Internet Engineering Task Force (IETF). Its stated mission is “To promote research of importance to the evolution of the future Internet by creating focused, long-term and small Research Groups working on topics related to Internet protocols, applications, architecture and technology.” 3 This work has been abandoned. and briefly discusses their appropriate placement within the OSI reference model. Having the definition of a security architecture according to [1] in mind, it is quite obvious that the OSI security architecture as specified in [3] and [4] does not con- form to it. In fact, the OSI security architecture rather refers to a terminological framework and a general description of security services and related security mech- anisms than a full-fledged security architecture. For convenience, we still use the term OSI security architecture in this book. But keep in mind that an e-∗ application usually requires a security architecture that is more comprehensive and situational. It may use the OSI security architecture as a starting point, but it normally has to go beyond it and be more specific. Table 1.1 Classes of OSI Security Services 1 Peer entity authentication service Data origin authentication service 2 Access control service 3 Connection confidentiality service Connectionless confidentiality service Selected field confidentiality service Traffic flow confidentiality service 4 Connection integrity service with recovery Connection integrity service without recovery Selected field connection integrity service Connectionless integrity service Selected field connectionless integrity service 5 Nonrepudiation with proof of origin Nonrepudiation with proof of delivery 1.1.1 Security Services As shown in Table 1.1, the OSI security architecture distinguishes between five classes of security services (i.e., authentication, access control, data confidentiality, data integrity, and nonrepudiation4 services). Just as layers define functionality in the OSI reference model, so do services in the OSI security architecture. These services may be placed at appropriate layers in the OSI reference model. 4 There is some controversy in the community regarding the correct spelling of the term “nonrepu- diation.” In fact, the OSI security architecture uses “non-repudiation” instead of “nonrepudiation,” and there are many people still using this spelling. In this book, however, we use the more modern spelling of the term without a hyphen. [Show More]

Last updated: 2 months ago

Preview 1 out of 261 pages