Slashdot Mirror
Book Review: Bulletproof SSL and TLS
benrothke writes If SSL is the emperor's new clothes, then Ivan Ristic in Bulletproof SSL and TLS has shown that perhaps the emperor isn't wearing anything at all. There is a perception that if a web site is SSL secured, then it's indeed secure. Read a few pages in this important book, and the SSL = security myth is dispelled. For the first 8 of the 16 chapters, Ristic, one of the greatest practical SSL./TLS experts around, spends 230 pages showing countless weaknesses, vulnerabilities, attacks and other SSL weaknesses. He then spends the next 8 chapters showing how SSL can, if done correctly, be deployed to provide adequate security. Keep reading for the rest of Ben's review.
Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications
author
Ivan Ristic
pages
530
publisher
Feisty Duck
rating
10/10
reviewer
Ben Rothke
ISBN
978-1907117046
summary
Tremendous guide on how to correctly deploy TLS by one of the top experts in the field
Ristic is the author of the SSL Labs web site; a site dedicated to everything SSL, including extensive documents and tools.
One would think that it's impossible to write an interesting book about a security protocol. But for those who use SSL or just want to understand what it's all about, the book is not only quite practical, but a very interesting read.
The book provides a good balance of overview, protocol details, summary of vulnerabilities and weaknesses, and a large chunk of practical deployment guidance.
The first three chapters provide an excellent overview to SSL, TLS, PKI and cryptography. While chapter 2 may be a bit dry, the introduction is thorough and comprehensive.
Chapter 4 is particularly interesting in that the author notes that while the cryptography behind SSL and PKI is fundamentally secure, there is an inherent flaw in how PKI operates, in that any CA (certificate authority) is able to issue a certificate for any name without have to seek approval from the domain name owner. This trust dependency creates numerous attack vectors that can be exploited.
The chapter details a number of significant incidents that arose from this flaw, from the 2001 code signing certificate mistake; where Verisign mistakenly issued Class 3 code signing certificates to someone claiming to be a Microsoft employee, to the Flame malware, which was signed with a bogus certificate that was seemingly signed by Microsoft, to a number of other issues.
In chapter 5, the book details a number of HTTP and browser issues, and related TLS threats. Attacks such as sidejacking, cookie stealing, cookie manipulation and more are detailed.
The author wisely notes that cookies suffer from two main problems: that they were poorly designed to being with, allowing behavior that encourages security weaknesses, and that they are not in sync with the main security mechanisms browsers use today, namely same-origin policy (SOP).
The chapter also details a significant TLS weakness in that that certificate warnings generated often leaves the clueless user to make the correct decision on how to proceed.
Ristic writes that if you receive an alert about an invalid TLS certificate, the right thing to do is immediately abandon the connection attempt. But the browser won't do that. Browser vendors decided not to enforce TLS connection security; rather they push the problem down to the user in the form of a certificate warning.
The problem is that when a user gets a certificate warning error, they simply don't know what to do to determine how big of an issue it really is, and will invariably choose to override the warning, and proceed to the website.
The challenge the user face is that these certificate warning errors are pervasive. In 2010, Ristic scanned about 119 million domain names (.com, .net and .org) searching for TLS enables sites. He found that over 22 million or 19% of the sites hosted in roughly 2 million IP addresses. But only about 720,000 had certificates whose names matches the intended hostname.
The chapter also details that the biggest problem with security indicators, similar to the certificate warnings, is that most users don't pay attention to them and possible don't even notice them.
As valuable as the first half of the book is, its significance really comes alive starting in chapter 8 on deployment issues. The level of security TLS offers only works when it is deployed correctly, and the book details how to do that. Given that OpenSSL, which is the most widely used SSL/TLS library, is notorious for being poorly documented and difficult to use, the deployment challenges are a significant endeavor.
Another issue with TLS, is that it can create performance issues and chapter 9 provides a lot of insight on performance optimization. The author quotes research from Google that SSL/TLS on their email systems account for less than 1% of the CPU load, less than 10kb of memory per connection, and less than 2% of the network overheard. The author writes that his goal is to enable the reader to get as close as possible to Google's performance numbers.
SSL/TLS has a reputation for being slow, but that is more a remnant of years ago when CPU's were much slower. With better CPU's and the optimization techniques the book shows, there is no reason not to use TLS.
For those that want an initial look, the table of contents, preface, and chapter 1 are available here. Once you get a taste of what this book has to offer, you will want to read the entire book.
As noted earlier, OpenSSL is poorly documented. In Bulletproof SSL and TLS, Ivan Ristic has done the opposite: he has written the most readable and insightful book about SSL/TLS to date. TLS is not so difficult to deploy, but incredibly easy to deploy incorrectly. Anyone who is serious about ensuring that their SSL/TLS deployment is effective should certainly read this book.
Reviewed by Ben Rothke.
You can purchase Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available from our review library please let us know.
One would think that it's impossible to write an interesting book about a security protocol. But for those who use SSL or just want to understand what it's all about, the book is not only quite practical, but a very interesting read.
The book provides a good balance of overview, protocol details, summary of vulnerabilities and weaknesses, and a large chunk of practical deployment guidance.
The first three chapters provide an excellent overview to SSL, TLS, PKI and cryptography. While chapter 2 may be a bit dry, the introduction is thorough and comprehensive.
Chapter 4 is particularly interesting in that the author notes that while the cryptography behind SSL and PKI is fundamentally secure, there is an inherent flaw in how PKI operates, in that any CA (certificate authority) is able to issue a certificate for any name without have to seek approval from the domain name owner. This trust dependency creates numerous attack vectors that can be exploited.
The chapter details a number of significant incidents that arose from this flaw, from the 2001 code signing certificate mistake; where Verisign mistakenly issued Class 3 code signing certificates to someone claiming to be a Microsoft employee, to the Flame malware, which was signed with a bogus certificate that was seemingly signed by Microsoft, to a number of other issues.
In chapter 5, the book details a number of HTTP and browser issues, and related TLS threats. Attacks such as sidejacking, cookie stealing, cookie manipulation and more are detailed.
The author wisely notes that cookies suffer from two main problems: that they were poorly designed to being with, allowing behavior that encourages security weaknesses, and that they are not in sync with the main security mechanisms browsers use today, namely same-origin policy (SOP).
The chapter also details a significant TLS weakness in that that certificate warnings generated often leaves the clueless user to make the correct decision on how to proceed.
Ristic writes that if you receive an alert about an invalid TLS certificate, the right thing to do is immediately abandon the connection attempt. But the browser won't do that. Browser vendors decided not to enforce TLS connection security; rather they push the problem down to the user in the form of a certificate warning.
The problem is that when a user gets a certificate warning error, they simply don't know what to do to determine how big of an issue it really is, and will invariably choose to override the warning, and proceed to the website.
The challenge the user face is that these certificate warning errors are pervasive. In 2010, Ristic scanned about 119 million domain names (.com, .net and .org) searching for TLS enables sites. He found that over 22 million or 19% of the sites hosted in roughly 2 million IP addresses. But only about 720,000 had certificates whose names matches the intended hostname.
The chapter also details that the biggest problem with security indicators, similar to the certificate warnings, is that most users don't pay attention to them and possible don't even notice them.
As valuable as the first half of the book is, its significance really comes alive starting in chapter 8 on deployment issues. The level of security TLS offers only works when it is deployed correctly, and the book details how to do that. Given that OpenSSL, which is the most widely used SSL/TLS library, is notorious for being poorly documented and difficult to use, the deployment challenges are a significant endeavor.
Another issue with TLS, is that it can create performance issues and chapter 9 provides a lot of insight on performance optimization. The author quotes research from Google that SSL/TLS on their email systems account for less than 1% of the CPU load, less than 10kb of memory per connection, and less than 2% of the network overheard. The author writes that his goal is to enable the reader to get as close as possible to Google's performance numbers.
SSL/TLS has a reputation for being slow, but that is more a remnant of years ago when CPU's were much slower. With better CPU's and the optimization techniques the book shows, there is no reason not to use TLS.
For those that want an initial look, the table of contents, preface, and chapter 1 are available here. Once you get a taste of what this book has to offer, you will want to read the entire book.
As noted earlier, OpenSSL is poorly documented. In Bulletproof SSL and TLS, Ivan Ristic has done the opposite: he has written the most readable and insightful book about SSL/TLS to date. TLS is not so difficult to deploy, but incredibly easy to deploy incorrectly. Anyone who is serious about ensuring that their SSL/TLS deployment is effective should certainly read this book.
Reviewed by Ben Rothke.
You can purchase Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available from our review library please let us know.
Browser vendors decided not to enforce TLS connection security; rather they push the problem down to the user in the form of a certificate warning.
That's, in part, because embedded software developers ship millions of devices with the same SSL certs. If the browser blocked a cert that doesn't match the hostname, no-one would be able to connect to them.
Of course, if they'd done that years ago, the embedded software developers would have had to find a more sensible solution. But it's far too late now.
"Chapter 4 is particularly interesting in that the author notes that while the cryptography behind SSL and PKI is fundamentally secure,"
Post-POODLE, SSL has been shown fundamentally insecure.
TLS is fine as far as we know.
Well yes, you should use SSL. It may have problems, but what's your other option?
I think if you're an IT worker-- one who's actually interested in his job-- then this information is probably of some interest. It sounds like a lot of it would be things I already know, but "How to setup SSL/TLS properly so that it uses the bare minimum of resources," seems like a helpful bit of information to have.
I have not seen very much moderated for myself, which is fine for the most part but I'm seeing a trend. Has the moderation system been killed and we have no notification that the system is dead? Here is some evidence. Yeah, you have some explaining to do!
3 moderated posts 2 funny 1 insightful.
0 moderated posts.
2 moderated posts 1 insightful 1 interesting.
0 moderated posts.
1 moderated post 1 insightful
No, this is not about me it's about concern for a system that has been repeatedly fucked with at the expense of the members.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
(hold on for a little bit longer.) I will publish drafts soon of how to using public keys for hosts. All public keys will be stored with a new DNS RR. (I'm writing the drafts at this very moment).
If you are going to comment on this, remember that I sad "hosts".
SSL/TSL/etc. are supposed to do two things:
1) Authenticate that you are talking to the machine you think you are talking to
2) Encrypt the traffic so that it would take a large amount of effort (ideally, an infeasible amount) for someone listening in to see the traffic.
SSL and TLS do make it difficult if not impossible for someone with just a wire-sniffer to decrypt the traffic. Typically they would either need the legal resources to get a court order to get the server's private keys, the technical resources to either acquire the keys another way or to fool you into connecting to their MITM machine, and/or the technical or other resources needed to compromise either your machine or the server. If they have that many resources, they may also have the resources to break into your house or office while you aren't there and install a hidden camera, at which time them snooping on your internet traffic suddenly becomes a lower-priority problem.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
The design flaws in earlier versions of SSL/TLS were found through bitter experiance. In generally you are much better off using a well-known protocol and understanding it's flaws, limitations and what options are appropriate to your application than trying to roll your own, it's silly to belive that you are less prone to making design errors than the designers of ssl and TLS were.
And some of the things you have to be mindful of are characteristics of variable rate encryption in general not specific to SSL/TLS, for example the fact that compression can cause changes in the content of the message to change the size of the message and this can leak information after encryption would apply to basically any encryption system that provides cypertext at a variable rate (theoretically you are much more secure with a system that outputs cyphertext at a constant rate even when no plaintext is coming in but for most people that would be too high a price to pay)
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
An invalid cert means you could be susceptible to a man in the middle attack. But even with an invalid cert, you're still more protected than without SSL. An educated user can make an educated decision. Unfortunately we are talking about mass market computer users, who as anyone in IT can tell you do the stupidest things imaginable on a daily basis. We're also dealing with web site operators that just want to put something up and let the server deal with everything with a minimum of hassle. Doing SSL at all is not easy, and doing it right is hard.
In the military, they have a standard that all technical manuals must be written for a 4th grade reading level. How to operate the tank? 400 pages that an average 10 year old could understand (with enough attention span). Every piece of open source software should have the same goal, not just for its documentation (you do have docs, right?), but for its API design. Instead, as I read in another comment by jandrese: "All of the APIs are apparently written with the thought that anyone messing with SSL should have PhD in cryptography first, because otherwise they're just going to screw it up."
I sometimes ask revealing, often ignorant-seeming questions. Maybe they're harder to answer than you think.