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.
It's meant to be simple middleware in network communication: almost transparent to applications, and with only a little system setup, like certs.
I can't imagine reading a five hundred thirty page book about it, much one essential.
Half of the chapters are used to show you how much SSL sucks and the other half are used to show you how to correctly deploy SSL so that it just barely doesn't suck but you should still use it anyway?
Get free satoshi (Bitcoin) and Dogecoins
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.
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.
they are not in sync with the main security mechanisms browsers use today, namely same-origin policy (SOP).
Really? What's different? (Yeah yeah: someone will tell me I should buy the book... I'll add to my book list and get to it by 2047).
I see the book price in the provided Amazon link as US$ 48.10 for the Paperback version.
Everyone sees the same price ?
Slashdot has given us a Amazon link - let's investigate if we get a lower or higher price when accesing the link from Slashdot as compared to other ways.
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
(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".
I wonder how long it will be before Ristic is disappeared. My money's on 110 days.
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.
For logging into a secure server the correct algoritmm is Secure Remote Password (SRP).
This uses a little crypto magic to produce STRONG security from weak passwords. It is a bit like using a nounce, but it does not give a man in the middle any way to brute force guess the password.
If the user tries to log into a phished website the attempt simply fails. The phisher learns nothing. And there is no need for all the PKI certificate signing trusted third party nonsense.
It is not just dumb end users. What do you do when an SSH session says "new certificate". Check its finger print? Of course not, nobody does. With SRP this would be completely unnecessary.
It does not work for sites upon which you have no account. But for banking etc. it is the obvious way to go. But somehow the PKI mob and their expensive certificates got all the press. And no patents on SRP.
(There are a number of similar algorithms known as PAKE. But SRP is the latest and greatest incarnation.)
"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."
Perhaps? PERHAPS??
If you're going to reference "the emperor's new clothes" then certainly the emperor isn't wearing anything at all. That is the very meaning of "the emperor's new clothes." Sheesh.
It gives you plenty of information and tool descriptions to test your own setups as you put them together. This, to me, was always the hardest part. Building LibreSSL fro source for the hell of it is also useful if for no other reason than getting the updated man pages. Just sayin'.
This book + wireshark = very, very informative, esp. if your background is in hardware design and not networking...
The heat from below can burn your eyes out
and the CA mechanism would work acceptably if CAs did their jobs diligently (which they don't all the time.)
They don't even pretend to, there are plenty of CAs who will hand you out a cert based on nothing more than sending an email to your domain (which of course is unencrypted and unauthenticated, remember you most likely don't have a cert yet....). If your hosting providers upstream ISP or a CAs upstream ISP is compromised by an attacker then they can easilly get the CA to issue them certs.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
That's not "lack of diligence", that's a fundamental bootstrapping problem. CA's are meant to verify identities. If the identity you are trying to verify is not itself cryptographically verifiable, then the attempt to verify can be tampered with, but the only way to solve that is to use harder to verify identities. Which is what EV certs do, and my own experience of getting one was pretty smooth.
We should concentrate on educating Web designers to only use HTTPS when it's really appropriate and necessary.
No we shouldn't. HTTPS should be everywhere. A somewhat insecure implementation of SSL is better than no SSL. Further, everything should be encrypted so that we can have some basic level of privacy. It's also not a good idea to raise a red flag for hackers to see over every "appropriate and necessary" use of strong encryption. And finally, if you want it to be illegal to spy on you, it helps to have the DMCA on your side. Any attempt to protect communications makes it a crime to break the encryption no matter how trivial it is to do so (based on my not lawyerly understanding; I am not responsible if this assumption gets you into trouble).
I sometimes ask revealing, often ignorant-seeming questions. Maybe they're harder to answer than you think.
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.
That's not "lack of diligence", that's a fundamental bootstrapping problem. CA's are meant to verify identities. If the identity you are trying to verify is not itself cryptographically verifiable, then the attempt to verify can be tampered with,
Agreed in general but I don't think a single email counts as "diligent verification". it's doing the bare minimum the browser vendors will let them get away with.
but the only way to solve that is to use harder to verify identities.
Specifically validating through multiple independent channels so that an attacker would have to compromise all of them to get the certificate.
The proper fix is to get rid of third party CAs entirely and integrate certification of domain ownership with the purchase of the domain.
Which is what EV certs do, and my own experience of getting one was pretty smooth.
EV helps a little but the web's page-by-page model works against it. The connection where a form is received and the connection where it is submitted are logically seperate and afaict there is nothing requiring them to use the same certificate. So an attacker who has a regular certicate for a domain that normally uses an EV certificate can avoid MITMing the initial connection (likely the request for the login form) and show the green bar. Then they can MITM the second connection and grab the form data.
I was dissapointed to find that HTTP strict transport security doesn't seem to do anything to address this.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register