Implementing SSL TLS using cryptography and PKI

Đây là bộ sách tiếng anh cho dân công nghệ thông tin chuyên về bảo mật,lập trình.Thích hợp cho những ai đam mê về công nghệ thông tin,tìm hiểu về bảo mật và lập trình.

Cryptography and PKI

Implementing SSL/TLS

Using Cryptography

and PKI

Joshua Davies

Wiley Publishing, Inc.

10475 Crosspoint Boulevard

Indianapolis, IN 46256

www.wiley.com

Copyright © 2011 by Wiley Publishing, Inc., Indianapolis, Indiana

Published simultaneously in Canada

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means,

electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or

108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or

autho-rization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive,

Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600 Requests to the Publisher for permission should be addressed

to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201)

748-6008, or online at http://www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with

respect to the accuracy or completeness of the contents of this work and specifi cally disclaim all warranties, including

without limitation warranties of fi tness for a particular purpose No warranty may be created or extended by sales or

promotional materials The advice and strategies contained herein may not be suitable for every situation This work

is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional

services If professional assistance is required, the services of a competent professional person should be sought

Neither the publisher nor the author shall be liable for damages arising herefrom The fact that an organization or

Web site is referred to in this work as a citation and/or a potential source of further information does not mean that

the author or the publisher endorses the information the organization or website may provide or recommendations

it may make Further, readers should be aware that Internet websites listed in this work may have changed or

disap-peared between when this work was written and when it is read.

For general information on our other products and services please contact our Customer Care Department within the

United States at (877) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.

Wiley also publishes its books in a variety of electronic formats Some content that appears in print may not be

avail-able in electronic books.

Library of Congress Control Number: 2010942196

Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc and/or

its affi liates, in the United States and other countries, and may not be used without written permission All other

trademarks are the property of their respective owners Wiley Publishing, Inc is not associated with any product or

vendor mentioned in this book.

Statements of Copyright: This book refers to and incorporates portions of the Internet Engineering Task Force (IETF’s)

Request For Comments (RFCs) All RFC are protected by the following copyright Copyright (C) The Internet Society

(1999) All Rights Reserved.

and this paragraph are included on all such copies and derivative works However, this document itself may not be modifi ed in any way, such as by removing the copyright notice or references to the Internet Society

or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defi ned in the Internet Standards process must be followed, or as required

to translate it into languages other than English The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR

Joshua Davies has been hacking on computers since his father brought home the family’s fi rst computer, a TI-99/4A,

in 1982 He holds a Bachelor’s degree in computer science from Valdosta State University and a Masters degree in computer science from the University of Texas at Arlington

He has been programming professionally since 1990 and

as a result has never had to do any real work He is rently responsible for security architecture at Travelocity com and previously worked internationally as a consultant for One, Inc whose client list included AT&T, Nieman Marcus, Intermedia, and the Mexican tele-communications giant Pegaso He prefers to work in C or assembler, but often codes in Java since it pays the bills He currently resides in Dallas, Texas with his wife and two children

cur-David Chapa is a Senior Analyst with the Enterprise Strategy Group ing the Data Protection segment with a focus on Disaster Recovery, Backup/

cover-Recovery as a Service, and Availability Solutions David has invested over 25 years in the computer industry, focusing specifi cally on data protection, data disaster recovery, and business resumption practices He has held several senior level technical positions with companies such as Cheyenne Software, OpenVision, ADIC, Quantum, and NetApp Prior to joining ESG, as Director

of Data Protection Strategy and Global Alliances for NetApp, David ued to evangelize “Recovery and Backup,” his mantra for over a decade now, and the benefi ts of integrating software solutions with disk-based backup

contin-In his role with ESG, David will bring all of this expertise, knowledge, and passion to raise a greater holistic awareness around data protection David

is an energetic and dynamic speaker who brings a great deal of experiential knowledge, humor, and keen insight to his audience He has been a featured speaker at VERITAS Vision, CA World, SNW, Chicago Software Association, and CAMP/IT Conferences, and has served as panelist on various discussions related to disaster recovery, compliance, and the use of disk, tape, and cloud for recovery and backup strategies

David has written several articles and blogs over the years In addition, he is

the co-author of Implementing Backup and Recovery, the Technical Editor of Cloud

Security, Security 2020, and Web Commerce Security Design and Development with

Wiley and Sons, and is recognized worldwide as an authority on the subject

of backup and recovery David is also a member of SNIA’s Data Protection and Capacity Optimization (DPCO) Committee, whose mission is to foster the growth and success of the storage market in the areas of data protection and capacity optimization technologies

Mary Beth Wakefi eld

Freelancer Editorial Manager

My name is the name on the cover of this book, but I can’t possibly take all

of the credit for the fi nished product I can’t thank the staff at John Wiley and Sons enough for their hard work and dedication in bringing this book to print — Charlotte Kughen for tirelessly correcting my overly casual use of the English language, David Chapa for his encouragement and gentle feedback, Maureen Spears for her infi nite patience with me every time I asked to make last-minute changes long after the time for last-minute changes had passed (I’m sure some day you’ll look back on this and laugh) and fi nally to Carol Long for understanding what I was trying to accomplish and expending so much effort

to get the green light for this project in the fi rst place

Thanks to the OpenSSL development team for their excellent software, which

I made such heavy use of while developing and testing the code in this book, and to Thomas Hruska of Shining Light Productions for his feedback as well

Many thanks to the IETF TLS working group who volunteer their time to erate free, openly accessibly specifi cations for no compensation beyond the satisfaction that they are making the world a better, safer place I’ve enjoyed debating and discussing the fi ner points of TLS with all of you while I was lurk-ing on the mailing list over the past three years This book is in no small part the culmination of the understanding I’ve achieved from listening to all of you

gen-I must, of course, acknowledge the support and encouragement gen-I received from my university professors long after graduation — especially to Dr Roger Lamprey, Dr Gergely Zaruba, and Dr Farhad Kamangar I have no idea what they’re paying you, but I’m sure it’s far less than you deserve

A special thank you goes to Troy Magennis of Travelocity, who encouraged

me to take the leap from thinking about writing a book to fi nally sitting down and making it happen Your example and inspiration were invaluable

Thank you to my parents and my brother and sisters who are fi ve of the most different, unique, and interesting people on the planet It’s amazing that

we’re all related, but somehow we pull it off Finally, thank you to my family

for their support as I wrote this book This took far longer and much more

effort than I ever anticipated For putting up with my long absences and lost

evenings and weekends as I wrote, re-wrote, and re-re-wrote: Lupita, Dylan,

and Isabelle — you are my purpose on this earth and my reason for being — I

hope I can always make you proud

And, of course, thanks to Tornado the cat for keeping my lap warm night after night as I wrote after everybody else had gone to bed

Introduction xxvii

Chapter 3 Secure Key Exchange over an Insecure Medium

Index 629

Introduction xxvii

“Insecure” Communications: Understanding the HTTP Protocol 4

Reliable Transmission of Binary Data with Base64 Encoding 17

Understanding Block Cipher Cryptography Algorithms 30Implementing the Data Encryption Standard (DES) Algorithm 31

Padding and Chaining in Block Cipher Algorithms 46Using the Triple-DES Encryption Algorithm to

Faster Encryption with the Advanced Encryption

Understanding Stream Cipher Algorithms 83Understanding and Implementing the RC4 Algorithm 84

Converting a Block Cipher to a Stream Cipher: The OFB and

Chapter 3 Secure Key Exchange over an Insecure Medium

Understanding the Theory Behind the RSA Algorithm 92Performing Arbitrary Precision Binary Math to

Implementing Large-Number Multiplication 101

Using Modulus Operations to Effi ciently Compute Discrete Logarithms in a Finite Field 113

Testing RSA Encryption and Decryption 126Achieving Perfect Forward Secrecy with

Getting More Security per Key Bit: Elliptic

How Elliptic Curve Cryptography Relies on

Using the Euclidean Algorithm to compute

Computing Modular Inversions with the Extended

Adding Negative Number Support to the Huge

Making ECC Work with Whole Integers: Elliptic-Curve

Reimplementing Diffi e-Hellman to Use ECC Primitives 150

Using Message Digests to Create Secure Document Surrogates 158Implementing the MD5 Digest Algorithm 159

Securely Hashing a Single Block of Data 166

Increasing Collision Resistance with the SHA-1

Understanding SHA-1 Block Computation 171Understanding the SHA-1 Input Processing Function 174

Even More Collision Resistance with the SHA-256

Preventing Replay Attacks with the HMAC

Implementing a Secure HMAC Algorithm 186

Appending the Length to the Last Block 194Computing the MD5 Hash of an Entire File 196Where Does All of This Fit into SSL? 200Understanding Digital Signature Algorithm

Implementing Sender-Side DSA Signature Generation 202Implementing Receiver-Side DSA Signature Verification 205

Getting More Security per Bit: Elliptic Curve DSA 210Rewriting the Elliptic-Curve Math Functions to

Putting It Together: The Secure Channel Protocol 222

Understanding Signed Certifi cate Structure 225Version 226serialNumber 227signature 227issuer 229validity 232subject 233subjectPublicKeyInfo 235extensions 237

Transmitting Certifi cates with ASN.1 Distinguished

ASN.1 Explicit Tags 244

Using OpenSSL to Generate an RSA KeyPair and Certificate 244Using OpenSSL to Generate a DSA KeyPair and Certificate 251

Converting a Byte Stream into an ASN.1 Structure 252

Turning a Parsed ASN.1 Structure into X.509 Certifi cate Components 264Joining the X.509 Components into a Completed X.509

Validating PKCS #7-Formatted RSA Signatures 280Verifying a Self-Signed Certificate 281Adding DSA Support to the Certificate Parser 286

How Authorities Handle Certifi cate Signing Requests (CSRs) 292Correlating Public and Private Keys Using PKCS #12

Formatting 293Blacklisting Compromised Certifi cates Using Certifi cate

Keeping Certifi cate Blacklists Up-to-Date with the Online

Chapter 6 A Usable, Secure Communications Protocol:

Flattening and Sending the Client Hello Structure 309

TLS Client Key Exchange 329Sharing Secrets Using TLS PRF

Creating Reproducible, Unpredictable Symmetric Keys

Correctly Receiving the Finished Message 352

Updating Each Invocation of send_message 359

Examining HTTPS End-to-end Examples (TLS 1.0) 369

Dissecting the Server Response Messages 372

Differences Between SSL 3.0 and TLS 1.0 378Differences Between TLS 1.0 and TLS 1.1 379

Implementing the TLS 1.0 Handshake from the

RSA Key Exchange and Private Key Location 395Supporting Encrypted Private Key Files 399Checking That Decryption was Successful 406

Chapter 8 Advanced SSL Topics 415

Passing Additional Information with Client Hello Extensions 415Safely Reusing Key Material with Session Resumption 420Adding Session Resumption on the Client Side 421

Adding Session Resumption Logic to the Client 422Restoring the Previous Session’s Master Secret 424

Adding Session Resumption on the Server Side 428Assigning a Unique Session ID to Each Session 429

Modifying parse_client_hello to Recognize Session

Avoiding Fixed Parameters with Ephemeral Key Exchange 436Supporting the TLS Server Key Exchange Message 437Authenticating the Server Key Exchange Message 439Examining an Ephemeral Key Exchange Handshake 442Verifying Identity with Client Authentication 448Supporting the Certifi cateRequest Message 449Adding Certificate Request Parsing Capability

Supporting the Certifi cate Verify Message 453Refactoring rsa_encrypt to Support Signing 453

Viewing a Mutually-Authenticated TLS Handshake 460Dealing with Legacy Implementations: Exportable Ciphers 463

Discarding Key Material Through Session Renegotiation 465

Renegotiation Pitfalls and the Client Hello

Defending Against the Renegotiation Attack 469

Supporting TLS 1.2 When You Use RSA for the Key Exchange 479

TLS 1.2 Modifi cations to the Finished Messages

Impact to Diffi e-Hellman Key Exchange 485

Adding Support for AEAD Mode Ciphers 490Maximizing Throughput with Counter Mode 490

Reusing Existing Functionality for Secure Hashes

Combining CTR and CBC-MAC into AES-CCM 496Maximizing MAC Throughput with Galois-Field

Authentication 502Combining CTR and Galois-Field Authentication

Incorporating AEAD Ciphers into TLS 1.2 517Working ECC Extensions into the TLS Library 523

Adding the NTTPS Extension to the NTTP Algorithm 543Implementing “Multi-hop” SMTP over TLS and

Protecting Email Content with S/MIME 545

Multipurpose Internet Mail Extensions (MIME) 547Protecting Email from Eavesdroppers with S/MIME 549Securing Email When There Are Multiple Recipients 550

Using the DNS Protocol to Query the Database 555

Preventing DNS Cache Poisoning with DNSSEC 556

The Decimal and Binary Numbering Systems 567Understanding Binary Logical Operations 568

Two’s-Complement Representation of Negative Numbers 570Big-Endian versus Little-Endian Number Formats 571

Appendix B Installing TCPDump and OpenSSL 573

Installing TCPDump on a Windows System 574

Installing OpenSSL on a Windows System 575

Examining an HTTPS End-to-End Example 619

This book examines the Secure Sockets Layer (SSL) and Transport Layer Security

(TLS) protocols in detail, taking a bottom-up approach SSL/TLS is a ized, widely implemented, peer-reviewed protocol for applying cryptographic primitives to arbitrary networked communications It provides privacy, integ-rity, and some measure of authenticity to otherwise inherently untrustworthy network connections Rather than just present the details of the protocol itself, this book develops, incrementally, a relatively complete SSL/TLS library First, all of the relevant cryptographic protocols are examined and developed, and then the library itself is built piece by piece

standard-All of the code developed in this book is C (not C++) code It’s been tested on both Windows and Linux systems and should run as advertised on either Although this is a code-heavy book, non-C programmers — or even non-programmers

in general — will still be able to get quite a bit from it All of the protocols and examples are presented in general form as well as in source code form so that

if you’re interested in a higher-level overview, you can skip the code examples and the book should still make sense

I chose C instead of C++ (or Java or Python or Perl, and so on) as a good common-denominator” language If you can program in any other procedural language, you can program in C; and if you can understand an implementation

“least-in C, you can understand an implementation “least-in any other language This book takes full advantage of the C programming language, though I use pointer syntax in particular throughout the book If you plan on following along with the code samples, make sure you’re comfortable with C and pointers I do my best to avoid the sort of excessive macro-ization and gratuitous typedef-ing that make professional C code easy to maintain but hard to read

You might be wondering, though, why I present the source code of yet another (partially incomplete) implementation when there are so many

good, tried-and-tested open-source implementations of SSL available Effectively,

production-grade libraries have (at least) fi ve primary concerns regarding

their source code:

1 It must work

2 It must be secure

3 It should be as fast as reasonably possible

4 It must be modular/extensible

5 It must be easy to read/understand

When a higher-numbered concern confl icts with a lower-numbered concern, the lower-numbered concern wins This must be the case for code that’s actu-

ally used by real people to perform real tasks The upshot is that the code is not

always pretty, nor is it particularly readable, when security/speed/modularity

take precedence The priorities for the code in this book are

1 It must work

2 It should be as readable as possible

Note that security, speed, and modularity aren’t concerns In fact, the code

presented in this book (somewhat ironically) is not particularly secure For

example, when the algorithms call for random bytes, the code in this book just

returns sequentially numbered bytes, which is the exact opposite of the random

bytes that the algorithm calls for This is done to simplify the code as well as

to make sure that what you see if you try it out yourself matches what you see

in the book

There isn’t any bounds-checking on buffers or verifi cation that the input matches what’s expected, which are things that a proper library ought to be

doing I’ve omitted these things to keep this book’s (already long) page count

under control, as well as to avoid obscuring the purpose of the example code

with hundreds of lines of error checking At various times throughout the book,

you’ll see code comments such as // TODO make this random or // TODO check

the length before using I’ve placed these comments in the code to draw your

attention to the functionality that was intentionally omitted

Of course, if you’re coding in a hostile environment — that is, if you’re ing with any production quality code — you should prefer a well-established

work-library such as OpenSSL, GnuTLS, or NSS over home-grown code any day

This book, however, should help you understand the internals of these

librar-ies so that, when it comes time to use one, you know exactly what’s going on

at all stages

Supplemental Web Sites

Every aspect of the Internet itself — including SSL/TLS — is described by a

series of documents written and maintained by the Internet Engineering Task Force (IETF) These documents are referred to (somewhat confusingly) as Requests for

Comments or, more commonly, just RFCs Each such RFC describes, authoritatively,

some aspect of some protocol related to the Internet And at the time of this writing, there are over 5000 such documents Although I doubt that anybody, anywhere, has actually read all of them, you’ll need to be familiar with quite

a few in order to do any serious Internet programming As such, I’ll refer to these RFCs by number throughout the book Rather than provide a link to each inline, I’ll just refer to them as, e.g., RFC 2246 If you want to see RFC 2246 (the authoritative document that describes TLS 1.0 itself), you can visit the IETF’s website at www.ietf.org Each RFC is stored in a document under http://www ietf.org/rfc/rfcnnnn.txt, where nnnn is the RFC number itself.

In addition, SSL/TLS borrows heavily from a couple of related standards

bodies — the International Telecommuncation Union (ITU) “X series” of ments and RSA laboratories’ Public Key Cryptography Standards (PKCS) The ITU

docu-standards can be found at http://www.itu.int/rec/T-REC-X/en and the PKCS standards can be found at http://www.rsa.com/rsalabs/node.asp?id=2124.

I’ll refer to RFC’s, X-series documents, and PKCS standards throughout the book You may want to bookmark these locations in a browser for quick refer-ence, if you’d like to compare the text to the offi cial standards documents All

of the standards documents referenced in this book are freely available and downloadable, so I don’t make any great effort to repeat them Instead, I try

to explain the background information that the standards documents always seem to take for granted I’m assuming that, if you’re interested in the low-level details, you can always refer to the standards document itself

Roadmap and Companion Source Code

I’ve been around and reading technical documentation since before there was

an Internet, or even CD-ROM drives Back in my day, readers of code-heavy books such as this one couldn’t just download the samples from a compan-ion website or an included CD-ROM If you wanted to see the code samples

in action, you had to type them in by hand Although typing code can be tedious at times, I’ve found that it’s also the best way to completely absorb the material So, Luddite that I am, I tend to eschew code downloads when I read technical material

This book has been designed so that somebody who wants to follow along can do so However, I also recognize that not every reader is a dinosaur like myself — er, I mean not everyone is quite so meticulous Changes to code

presented previously are listed in boldface, so it’s easy to see what’s been

modi-fi ed and what’s been left unchanged

The companion website at http://www.wiley.com/go/implementingsslhas two download fi les — one for GCC for those following along on a Linux

platform and one for Visual Studio for those following along on Windows Each

download is split into two sections: one that includes the fi nished code for each

chapter and another for somebody who might want to follow along I urge you

to download at least the code for following along because it includes Makefi les

and headers that aren’t specifi cally reproduced in this book This book’s code

is heavily self-referential — especially in the second half — so you want to

be sure to build correctly The downloadable Makefi les ensure that you can

Because this book is about SSL, I try my best not to get too hung up on lated implementation details However, the code presented here does work

unre-and is somewhat nontrivial, so some “implementation asides” are unavoidable

Outline of the Book

Chapter 1, “Understanding Internet Security,” examines the basics of Internet

communication and what is and is not vulnerable to attackers To motivate the

remainder of the book, a basic working HTTP example is developed here Later

chapters incrementally add security features to this beginning HTTP example

Chapter 2, “Protecting Against Eavesdroppers with Symmetric Cryptography,”

examines the aspect of communications security that most people think of

fi rst, which is scrambling data in fl ight so that it can’t be intercepted or read

by unauthorized parties There are many internationally recognized standard

algorithms in this space, which SSL/TLS rely heavily on Chapter 2 examines

three of these standards in detail: DES, AES and RC4 The code developed here

will be reused in Chapter 6 when the actual TLS library is built

Chapter 3, “Secure Key Exchange over an Insecure Medium with Public Key Cryptography,” looks at the problem of exchanging keys when the underlying

communications channel can’t be trusted The thorny problem of how to take an

unencrypted link and turn it into an encrypted one is examined here There are

also several standards in this area — RSA, Diffi e-Hellman, and Elliptic-Curve

Cryptography are examined in detail in this chapter

Chapter 4, “Authenticating Communications Using Digital Signatures,” ines a less prominent, but equally as important, aspect of secure communications

exam-While cryptography protects data from eavesdroppers, authentication protects

data against forgers The standards MD-5, SHA-1, SHA-256, HMAC, DSA, and

ECDSA are all examined in detail in this chapter Each of these plays a key role

in TLS as discussed further in Chapter 6

Chapter 5, “Creating a Network of Trust Using X.509 Certifi cates,” discusses the fi nal piece of the PKI puzzle that the previous two chapters began, digital

certifi cates Digital certifi cates and the Public-Key Infrastructure that support

them are required to guard against active attacks TLS depends greatly on certifi cates, so this chapter develops an ASN.1 parser and an X.509 certifi cate reader, which is used in the next chapter to authenticate web sites securely.

Chapter 6, “A Usable, Secure Communications Protocol: Client-Side TLS,” ties together all of the concepts from the previous four chapters into a working TLS implementation This chapter looks at TLS from the perspective of the client and ends with a working HTTPS implementation

Chapter 7, “Adding Server-Side TLS 1.0 Support,” takes the foundation of TLS from Chapter 6 and expands it to the web server example from Chapter

1, developing an SSL-enabled mini–web server Since the server needs to store private keys, which are, by their nature, especially sensitive, Chapter 7 also examines the topic of using password to securely encrypt data at rest

Chapter 8, “Advanced SSL Topics,” covers the rest of TLS 1.0 — there are several optional elements that a compliant implementation ought to sup-port, but which are not as widespread as the most common case covered in Chapters 6 and 7 Client authentication, server name identifi cation, export grade cryptography, session resumption, and session renegotiation are all explored in depth here

Chapter 9, “Adding TLS 1.2 Support to Your TLS Library,” implements the latest version of the TLS protocol, 1.2, on top of the TLS 1.0 implementation that Chapters 6–8 developed Here you see elliptic curve cryptography put to use

Additionally, AEAD-mode ciphers are examined, since TLS 1.2 is the fi rst sion of TLS to permit this mode

ver-Chapter 10, “Other Applications of SSL,” takes a look at the non-HTTP uses that SSL/TLS has been put to The STARTTLS extension and DTLS are examined here Also, S/MIME and DNSSEC — not strictly TLS, but related — are covered

in this chapter Finally, Chapter 10 ends by looking at how HTTPS supports HTTP proxies, which is, overall, an interesting compromise

How to Read This Book

This book was written to be read cover to cover Additionally, if you have some background in C programming, you will want to read through, and probably compile and run, the code samples If you’re not a programmer, or not particularly comfortable with the C programming language, you can skip over the code samples and just read the text descriptions of the relevant pro-tocols — the book was written to make sense when read this way The benefi t

of the code samples is that it’s impossible to omit any detail — accidentally or intentionally — when writing code, so if you can understand the code, it will cement your understanding of the text preceding it I’ve made every effort to ensure that the text and diagrams describe the protocols exactly If, however,

in spite of my best efforts, my descriptions are for any reason unclear, you can always step through the code to see exactly what’s going on

Although this is a book about SSL/TLS, the fi rst half of the book just sets the stage for SSL/TLS by presenting all of the protocols and standards they rely

on If you’re just looking for a description of TLS, and have a reasonable

under-standing of cryptography and PKI in general, you should be able to safely skip

ahead to Chapter 6 and start there with the overview of TLS itself However,

at some point, you should jump back and read Chapters 2–5, since there are a

lot of implementation details that can bite you in surprising ways when using

cryptographic libraries My primary motivation in writing this book was to

present, in detail, the interplay between the SSL and TLS protocols and the

cryptographic routines that they rely on

Understanding Internet Security

How secure is the data that you transmit on the Internet? How vulnerable is your personal data to hackers? Even computer-literate, experienced program-mers fi nd it’s hard to answer these questions with certainty You probably know that standard encryption algorithms are used to protect data — you’ve likely heard of public-key algorithms such as RSA and DSA — and you may know that the U.S government’s Data Encryption Standard has been replaced by an Advanced Encryption Standard Everybody knows about the lock icon in their browsers that indicates that the session is protected by HTTPS You’ve most likely heard of PGP for e-mail security (even if you gave up on it after failing

to convince your friends to use it)

In all likelihood, though, you’ve also heard of man in the middle attacks, timing

attacks, side-channel attacks, and various other attacks that aim to compromise

privacy and security Anybody with a web browser has been presented with the ominous warning message that “This site’s security cannot be trusted — either the certifi cate has expired, or it was issued by a certifi cate authority you have chosen not to trust.” Every week, you can read about some new zero-day exploit uncovered by security researchers that requires a round of frantic patching As

a professional programmer, you may feel you ought to know exactly what that means — yet trying to decipher these messages and determine whether you should really be worried or not takes you down the rabbit hole of IETF, PKCS, FIPS, NIST, ITU, and ASN You may have tried to go straight to the source and read RFC 2246, which describes TLS, but you may have discovered, to your

chagrin, that RFC 2246 presumes a background in symmetric cryptography,

public-key cryptography, digital signature algorithms, and X.509 certifi cates

It’s unclear where to even begin Although there are a handful of books that

describe SSL and “Internet Security,” none are targeted at the technically inclined

reader who wants, or needs, to know the details

A mantra among security professionals is that the average programmer doesn’t understand security and should not be trusted with it until he verses

himself in it This is good, but ultimately unhelpful, advice Where does one

begin? What the security professionals are really trying to tell you is that, as a

practitioner rather than a casual user, it’s not enough to treat security as a black

box or a binary property; you need to know what the security is doing and how

it’s doing it so that you know what you are and aren’t protected against This

book was written for you — the professional programmer who understands the

basics of security but wants to uncover the details without reading thousands

of pages of dry technical specifi cations (only some of which are relevant)

This book begins by examining sockets and socket programming in brief

Afterward, it moves on to a detailed examination of cryptographic concepts

and fi nally applies them to SSL/TLS, the current standard for Internet security

You examine what SSL/TLS does, what it doesn’t do, and how it does it After

completing this book, you’ll know exactly how and where SSL fi ts into an

over-all security strategy and you’ll know what steps yet need to be taken, if any, to

achieve additional security

What Are Secure Sockets?

The Internet is a packet-switching network This means that, for two hosts to

com-municate, they must packetize their data and submit it to a router with the

destina-tion address prepended to each packet The router then analyzes the destinadestina-tion

address and routes the packet either to the target host, or to a router that it

believes is closer to the target host The Internet Protocol (IP), outlined in RFC

971, describes the standard for how this packetization is performed and how

addresses are attached to packets in headers

A packet can and probably will pass through many routers between the sender and the receiver If the contents of the data in that packet are sensitive — a pass-

word, a credit card, a tax identifi cation number — the sender would probably

like to ensure that only the receiver can read the packet, rather than the packet

being readable by any router along the way Even if the sender trusts the

rout-ers and their operators, routrout-ers can be compromised by malicious individuals,

called attackers in security terminology, and tricked into forwarding traffi c that’s

meant for one destination to another, as shown in http://www.securesphere

.net/download/papers/dnsspoof.htm If you’d like to get an idea just how many

different hosts a packet passes through between you and a server, you can use

the traceroute facility that comes with every Internet-capable computer to print

a list of the hops between you and any server on the Internet

An example of a traceroute output is shown below:

[jdavies@localhost]:~$ traceroute www.travelocity.com traceroute to www.travelocity.com (151.193.224.81), 30 hops max, 40 byte packets

6 gig0-1-0.dllatxl3-rtr1.texas.rr.com (72.179.205.72) 69.604 ms 37.540 ms 14.015 ms

or will not do so are represented with * * * in the preceding code Typically the routers don’t respond because they’re behind a fi rewall that’s confi gured not to forward ICMP diagnostic packets As you can see, there are quite a few hops between my home router and Travelocity’s main web server

In network programming parlance, the tenuous connection between a sender

and a receiver is referred to as a socket When one host — the client — is ready

to establish a connection with another — the server — it sends a synchronize

(SYN) packet to the server If the server is willing to accept the connection,

it responds with a SYN and acknowledge packet Finally, the client edges the acknowledgment and both sides have agreed on a connection This

acknowl-three-packet exchange is referred to as the TCP handshake and is illustrated in Figure 1-1 The connection is associated with a pair of numbers: the source port and the destination port, which are attached to each subsequent packet in the

communication Because the server is sitting around, always listening for nections, it must advertise its destination port ahead of time How this is done

con-is protocol-specifi c; some protocols are lucky enough to have “magic numbers”

associated with them that are well-known (in other words, you, the programmer

are supposed to know them) This is the Transport Control Protocol (TCP); RFC

793 describes exactly how this works and how both sides agree on a source and

destination port and how they sequence these and subsequent packets

Figure 1-1: TCP three-way handshake

ACK SYN/ACK SYN

server client

TCP and IP are usually implemented together and called TCP/IP A socket refers

to an established TCP connection; both sides, client and server, have a socket

after the three-way handshake described above has been completed If either side

transmits data over this socket, TCP guarantees, to the best of its ability, that the

other side sees this data in the order it was sent As is required by IP, however,

any intermediate router along the way also sees this data

SSL stands for Secure Sockets Layer and was originally developed by Netscape

as a way to allow the then-new browser technology to be used for e-commerce

The original specifi cation proposal can be found in http://www.mozilla.org/

projects/security/pki/nss/ssl/draft02.html Although it has since been

standardized and renamed Transport Layer Security (TLS), the name SSL is much

more recognizable and in some ways describes better what it does and what

it’s for After a socket has been established between the client and the server,

SSL defi nes a second handshake that can be performed to establish a secure

channel over the inherently insecure TCP layer

“Insecure” Communications: Understanding the

HTTP Protocol

HTTP, or Hypertext Transport Protocol, which is offi cially described in RFC 2616,

is the standard protocol for web communication Web clients, typically referred

to as browsers, establish sockets with web servers HTTP has a well-known

destination port of 80 After the socket has been established, the web browser

begins following the rules set forth by the HTTP protocol to request documents

HTTP started out as a fairly simple protocol in which the client issued a GET

command and a description of what it would like to get, to which the server

responded with either what the client requested in document form or an error indicating why it could not or did not give the client that document Either way, the socket would be closed after this If the client wanted another docu-ment, it would create another socket and request another document Over the years, HTTP has been refi ned quite a bit and optimized for bandwidth, speed, and security features.

HTTP was also the primary motivator for SSL Originally, SSL didn’t stand

on its own; it was designed as an add-on to HTTP, called HTTPS Although SSL was subsequently decoupled from HTTP, some of its features were optimized for HTTP, leaving it to be a bit of a square peg in a round hole in some other contexts Because HTTP and SSL go so well together, in this book I motivate SSL

by developing an HTTP client and adding security features to it incrementally,

fi nally arriving at a working HTTP/SSL implementation

Implementing an HTTP Client

Web browsers are complex because they need to parse and render HTML — and,

in most cases, render images, run Javascript, Flash, Java Applets and leave room for new, as-yet-uninvented add-ons However, a web client that only retrieves

a document from a server, such as the wget utility that comes standard with most Unix distributions, is actually pretty simple Most of the complexity is in the socket handling itself — establishing the socket and sending and receiving data over it

Start with all of the includes that go along with socket communication — as you can see, there are quite a few, shown in Listing 1-1

Listing 1-1: “http.c” header includes

The main routine is invoked with a URL of the form http://www.server com/path/to/document.html You need to separate the host and the path using

a utility routine parse_url, shown in Listing 1-2

Listing 1-2: “http.c” parse_url

/**

* Accept a well-formed URL (e.g http://www.company.com/index.html) and return

* pointers to the host part and the path part Note that this function

* modifies the uri itself as well It returns 0 on success, -1 if the URL is

* found to be malformed in any way.

that the calling function passes in two pointers to pointers; these should be

null when the function starts and will be modifi ed to point into the uri string,

which came from argv

The main routine that coordinates all of this is shown in Listing 1-3

Listing 1-3: “http.c” main

#define HTTP_PORT 80

/**