Eric Rescorla

Mentioned 7

""This is the best book on SSL/TLS. Rescorla knows SSL/TLS as well as anyone and presents it both clearly and completely.... At times, I felt like he's been looking over my shoulder when I designed SSL v3. If network security matters to you, buy this book."" Paul Kocher, Cryptography Research, Inc. Co-Designer of SSL v3 " "Having the right crypto is necessary but not sufficient to having secure communications. If you're using SSL/TLS, you should have "SSL and TLS"sitting on your shelf right next to "Applied Cryptography." Bruce Schneier, Counterpane Internet Security, Inc. Author of "Applied Cryptography"" "Everything you wanted to know about SSL/TLS in one place. It covers the protocols down to the level of packet traces. It covers how to write software that uses SSL/TLS. And it contrasts SSL with other approaches. All this while being technically sound and readable!"" Radia Perlman, Sun Microsystems, Inc. Author of "Interconnections" Secure Sockets Layer (SSL) and its IETF successor, Transport Layer Security (TLS), are the leading Internet security protocols, providing security for e-commerce, web services, and many other network functions. Using SSL/TLS effectively requires a firm grasp of its role in network communications, its security properties, and its performance characteristics. "SSL and TLS" provides total coverage of the protocols from the bits on the wire up to application programming. This comprehensive book not only describes how SSL/TLS is supposed to behave but also uses the author's free ssldump diagnostic tool to show the protocols in action. The author covers each protocol feature, first explaining how it works and then illustrating it in a live implementation. This unique presentation bridges the difficult gap between specification and implementation that is a common source of confusion and incompatibility. In addition to describing the protocols, "SSL and TLS" delivers the essential details required by security architects, application designers, and software engineers. Use the practical design rules in this book to quickly design fast and secure systems using SSL/TLS. These design rules are illustrated with chapters covering the new IETF standards for HTTP and SMTP over TLS. Written by an experienced SSL implementor, "SSL and TLS" contains detailed information on programming SSL applications. The author discusses the common problems faced by implementors and provides complete sample programs illustrating the solutions in both C and Java. The sample programs use the free OpenSSL and PureTLS toolkits so the reader can immediately run the examples. 0201615983B04062001

More on

Mentioned in questions and answers.

Since SSL is the backbone of the secure internet, (now technically called TLS), what are some good books I should read up on to understand all aspects of it?

I suppose I'll need to learn some math, some PKI books, crypto, and Sysadmin books as well. Since that isn't a complete list I'm interested in hearing what you think is wise to learn as well.

As far as cryptography goes, this is the best there is:

Applied Cryptography: Protocols, Algorithms, and Source Code in C

You will learn all there is from the basic building blocks upwards.

I had a problem with accepting invalid SSL certificate in my iPhone program. That problem is solved now, however I came to understanding that I have very abstract idea on how exactly the whole thing is working:

  • how web browser is verifying that received certificate is really for host it communicates to and not faked by same party in the middle?
  • if browser talks to some 3rd party (CA?) to do certificate check?

and many other questions... Would someone please recommend good source of information with in-depth enough description of how all parts click together?

I've read and watched a lot of articles and videos about SSL AES and RSA, but one thing is ALWAYS missing in every explanation( or I just don't get it ) is how the client decrypts sensitive data that comes from the server!(e.g. how much money you have)

I get it that your public key can encrypt anything and send it to the server and anyone can have it, but what do you do when you want to retrieve something from the server? Does it comes just as plain text?

Any of the articles and videos point that out, they all just say that you have a private key that you shouldn't share and a public key that you can encrypt your messages and share it in the internet, but they don't say how the client makes a GET request with a encrypted message and decrypt it so it can be human readable.

As it says in this link about AES:

Asymmetric cryptography works by having two different keys, one for encryption and one for decryption. It's also often called 'public key cryptography' because it's possible to make one key public (allowing someone to encrypt a message) while keeping the other private (only the holder of the private key can decrypt the message encrypted with its related public key).

Any help is welcome!

I will leave some links about web security that I found useful to learn:

If you want all the details grab a copy of SSL and TLS: Designing and Building Secure Systems. For a more arid lecture, read RFC2246 The Transport Layer Security (TLS) Protocol.

The short story is this: during the TLS/SSL handshake the client and the server exchange a secret (the PMS, pre-master-secret). This secret is used to derive session keys, initialization vectors and HMAC keys for use by client and server. Each one uses this keys to encrypt and sign everything send from it's side, and each one use the other's key to decrypt and validate the data sent by the other. Nothing ever goes in clear text, in any direction.

Authorization and authentication based on the certificate used is a completely orthognal issue.

I'm adding SSL support (currently pushing forward with OpenSSL) to an existing application. I've never done anything with cryptology before and after reading numerous articles and watching videos I'm still a little confused as to how I can implement it for my specific situation.

Our software is client/server, and the end-user purchases both and will install it on their premises.

My first bit of confusion is regarding certificates and private keys, and how to manage these. Should I have one certificate that get installed along with the app? Should each end-user have their own certificate generated? What about private keys? Do I bake the private key into the server binary? Or should there be a file with the private key?

I'm sure this is a solved problem, but I'm not quite sure where to look, or what to search for.

Thanks for any help and advice.

Adding OpenSSL into existing app

If all you need is an example of a SSL/TLS client, have a look at the OpenSSL's wiki and TLS Client example.

My first bit of confusion is regarding certificates and private keys, and how to manage these.

Yes, key management and distribution is the hardest problem in crpyto.

Public CAs have legally binding documents covering these practices. They are called Certification Practice Statements (CPS). You can have a lot of fun with them because the company lawyers tell you what you don't want to hear (or the marketing department refuses to tell you).

For example, here's an excerpt from Apple Inc. Certification Authority Certification Practice Statement:

2.4.2. CA disclaimers of warranties
To the extent permitted by applicable law, Subscriber agreements,
if applicable, disclaim warranties from Apple, including any
warranty of merchantability or fitness for a particular purpose.

2.4.3. CA limitations of liability
To the extent permitted by applicable law, Subscriber agreements,
if applicable, shall limit liability on the part of Apple and shall
exclude liability for indirect, special, incidental, and
consequential damages.

So, Apple is selling you a product with no warranty and that offers no liability!!! And they want you to trust them and give them money... what a racket! And its not just Apple - other CAs have equally obscene CPS'es.

Should I have one certificate that get installed along with the app?

It depends. If you are running your own PKI (i.e., you are the CA and control the root certificate), then distribute your root X509 certificate with you application and nothing else. There's no need to trust any other CAs, like Verisign or Startcom.

If you are using someone else's PKI (or the Internet's PKI specified in RFC 5280), then distribute only the root X509 certificate needed to validate the chain. In this case, you will distribute one CA's root X509 certificate for validation. You could potentially trust just about any certificate signed by that particular CA, however (and its likely to be in the 10's of thousands if you are not careful).

If you don't know in advance, then you have to do like browsers and pick a bunch of CAs to trust and carry around their root certificates for your application. You can grab a list of them from Mozilla, for example. You could potentially trust just about any certificate signed by all CAs, however (and its likely to be in the 10's of millions if you are not careful).

There's a lot more to using public CAs like browsers, and you should read through Peter Gutmann's Engineering Security. Pay particular attention to the Security Diversification strategies.

When the client connects to your server, your server should send its X509 certificate (the leaf certificate) and any intermediate certificates required to build a valid chain back to the root certificate you distribute.

Finally, you can get free SSL/TLS certificates trusted by most major browsers (including mobile) from Eddy Nigg at Startcom. He charges for the revocation (if needed) because that's where the cost lies. Other CAs charge you up front and pocket the proceeds if not needed.

Should each end-user have their own certificate generated?

That is possible, too. That's called client certificates or client authentication authentication. Ideally, you would be running your own PKI because (1) you control everything (including the CA operations) and don't need to trust anyone outside the organization; and (2) it can get expensive to have a commercial CA sign every user's certificate.

If you don't want to use client side certificates, please look into PSK (Preshared Keys) and SRP (Secure Remote Password). Both beat the snot out of classic X509 using RSA key transport. PSK and SRP do so because they provide mutual authentication and channel binding. In these systems, both the client and server know the secret or password and the channel is setup up; or one (or both) does not know and channel setup fails. The plain text username and password are never put on the wire as in RSA transport and basic_auth schemes. (I prefer SRP because its based on Diffie-Hellman, and have implemented it in a few systems).

What about private keys?

Yes, you need to manage the private keys associated with certificates. You can (1) store them in the filesystem with permissions or ACLs; (2) store them in a Keystore or Keychain like Android, Mac OS X, iOS, or Windows; (3) store them in an Hardware Security Module (HSM); or (4) store them remotely while keeping them online using Key Management Interop Protocol (KMIP).

Note: unattended key storage on a server is a problem without a solution. See, for example, Peter Gutmann's Engineering Security, page 368 under "Wicked Hard Problems" and "Problems without Solutions".

Do I bake the private key into the server binary?

No. You generate them when needed and then store them with the best protection you can provide.

Or should there be a file with the private key?

Yes, something like that. See above.

I'm sure this is a solved problem, but I'm not quite sure where to look, or what to search for.

I'm not sure I would really call it solved because of the key distribution problem.

And some implementations are just really bad, so you would likely wonder how the code passed for production.

The first thing you probably want (since your focusing on key management) is a treatment of "key management" and "key hierarchies".

You might also want some reference material. From the security engineering point of view, read Gutmann's Engineering Security and Ross Anderson's Security Engineering. From an implementation standpoint, grab a copy of Network Security with OpenSSL and SSL and TLS: Designing and Building Secure Systems.

I need to write my own SSL socket (CSocket ansestor) with server side certificate validation using Microsoft CryptoAPI.

Can you tell me which book will help me (or any other user friendly source of information)?

I recommend SSL and TLS by Eric Rescorla (author of ssldump) to get a really good understanding of SSL. It provides a great introduction to the protocol and the problems it solves, with the option to go as deep as you want into the details.

I would also strongly recommend not writing your own implementation unless you really have to.

can somebody advise me good "How to" or Manual. It is match micro articles how to use specific algorithms or very large books about crypto lib. I am trying to find something in between, something that would allow me to quickly start with this lib.

Can somebody advise me good "How to" or Manual?

You can find HowTo's sprinkled across the web.

The manual is located online at OpenSSL Documents. The same manual is installed locally, and you access it via the man pages. For example, you can find information on ciphers with ciphers(1). You can find it online at ciphers(1), or by typing man 1 ciphers.

You can also visit the OpenSSL wiki. Block ciphers are covered at EVP Symmetric Encryption and Decryption and EVP Authenticated Encryption and Decryption. MACs are covered at EVP Message Digests.

There are a couple of books, but they are a bit dated. They are still good reference since everything presented is still in use (there's just more stuff now). See Network Security with OpenSSL and SSL and TLS: Designing and Building Secure Systems.

Finally, when you can't find information on something, the last line is the source code. Nearly all functionality is demostrated in the various subcommands. For example, pkcs8 is a subcommand in openssl pkcs8 .... You can find the source code in <openssl src dir>/apps/pkcs8.c.

If I have a Silverlight client connecting to a web service hosted in a windows service, there's no obvious way to secure communications between the two if you're not using IIS. SSL isn't available, and wsHttpBinding isn't supported by Silverlight.

So here's what I'm planning on doing, and just wanted to see if I'd missed any obvious security holes. This will all be on an intranet, SSL-secured hosting on IIS will be used if we ever make it internet-enabled.

  1. Create a certificate and put it in the user store for the service account for the web service. Web-service retrieves the certificate keys on startup.
  2. Add a clear-text method to the web service to return the public key from the certificate as a string.
  3. Call the web-service from the Silverlight client to get the public key.
  4. Encrypt all data sent to the web-service from the Silverlight client using the public key. The data returned to the Silverlight client does not need to be encrypted.

Am I missing anything? I can't figure out any other way to do it!

You can't encrypt large ammounts of data with RSA cryptography, is just too darn slow (100s of ms per RSA modulus length I think). All schemes use RSA to bootstrap a symmetric key and encrypt the data using this key. Use any of the established key exchange protocols. You'd be surprised how easy is to implement SSL 3.0 or TLS 1.0 if you have a copy of Rescorla's book SSL and TLS: Designing and Building Secure Systems