Book Review: Bulletproof SSL and TLS 92
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.
Ristic is the author of the SSL Labs web site; a site dedicated to everything SSL, including extensive documents and tools. | 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 |
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 an encryption layer (Score:2)
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.
Re: (Score:2)
Well based on the summary, I'm at least intrigued. I know personally I could use a refresher on it, especially with the recent vulnerabilities made public.
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
Sure there is. Perhaps not in C but what did you expect? Here we go in Java:
HttpsUrlConnection conn = (HttpsUrlConnection) new URL("https://www.google.com/").openConnection();
Certificate[] certs = conn.getServerCertificates();
InputStream stream = conn.ge
Re: (Score:2)
Re: (Score:2)
It's meant to be, unfortunately we have learnt the hard way that the abstraction is leaky and people keep discovering new ways in which it leaks.
So is that a yes or a no? (Score:2)
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
Re: (Score:3)
Re: (Score:2)
Hand rolled encryption scheme you have to install drivers for on all your users' computers, of course.
It'll be perfectly secure, because no one will use it.
Re: (Score:2)
Re: (Score:1)
Hand rolled encryption scheme you have to install drivers for on all your users' computers, of course.
It'll be perfectly secure, because no one will use it.
That doesn't make it secure, only a potentially less desirable target.
Re: (Score:2)
Zero traffic means zero traffic interceptions.
Re: (Score:1)
Re: (Score:2)
There are no realistic alternatives. Opportunistic IPSEC never got started, and I am not aware of any other attempts which might actually work. You can replace the CA system with DNSSEC, but that does not solve the entire problem.
Re: (Score:2)
Thank you
Chewie, take the professor in the back and plug him into the hyperdrive!
Re: (Score:2)
SSL is subject to vulnerabilities, weaknesses and misconfiguration like every other protocol and piece of software.
It’s for the most part all we have until a SSL replacement is found.
With that, you can maximize its usefulness by deploying it correctly, as per the 2nd half of the book.
Re: (Score:3)
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/
Certificate warnings (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
Haha... I've been making a MITM proxy for debugging purpose (there's a few out there, ie: Fiddler, CharlesProxy, etc), and have been wondering for like ever why some sites seemed to handle poor certificate configuration differently than others (ie: I can MITM Google.com with a self signed certificate thats trusted, but I can't MITM account.google.com without proper SHA256 and a certificate authority chain...).
Its because of that header. I had never heard about it (hard to find something you don't know you'r
SSL? (Score:3)
"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.
Re: (Score:3)
Post-POODLE, SSL has been shown fundamentally insecure.
POODLE is an implementation problem, not a fundamental cryptography problem.
Practically speaking, it doesn't make much difference. Security is no better than your implementation.
Re: (Score:2)
POODLE is not an implementation problem. It's a protocol problem.
https://www.us-cert.gov/ncas/alerts/TA14-290A [us-cert.gov]
"There is currently no fix for the vulnerability SSL 3.0 itself, as the issue is fundamental to the protocol"
It's an implementation problem if you're speaking abstractly about the application of crypto. But we're talking about "SSL", a protocol.
Re: (Score:2)
Re: (Score:2)
That's an excellent article, thanks.
The fix would require specific changes to the implementation and "...there's a high risk that this would also cause compatibility problems." IMHO, it would be highly misleading to call it an implementation problem that an unforseen encryption weakness could be mitigated with changes to the implementation.
I offer the above to be XKCD1318 [xkcd.org] compliant.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
is the combination of sensitive application and user supplied data sent over the same stream in both directions.
I'm not seeing how that's the problem. Ultimately it's all going to go across (roughly) the same IP pathway, right?
Re: (Score:2)
POODLE, BREACH, CRIME etc all require the attacker to control some bytes in the ssl stream in order to deduce other bytes that they shouldn't be able to see. POODLE requires the attacker to change the http url & form post body in order to force the alignment of bytes, BREACH and CRIME are gzip length attacks. Both require the attacker to control bytes in a http request in order to guess the contents of other bytes in the request that they wish to know, like a session cookie.
All of these are attacks on
HEY DICE, WHAT THE FUCKHAPPENED TO MODERATING? (Score:3, Interesting)
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 [slashdot.org] 2 funny 1 insightful.
0 moderated posts. [slashdot.org]
2 moderated posts [slashdot.org] 1 insightful 1 interesting.
0 moderated posts. [slashdot.org]
1 moderated post [slashdot.org] 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.
Re: (Score:3)
I also suspect moderation has slowed down. I suspect more generally long-term members with good karma and mod points have been coming here less due to the content and the beta site.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I received an email from a moderator that they thought the messaging issue was fixed. Looks like it is now, as I'm starting to see responses from the last week pour in.
So lets see if they can answer why moderation seems to be borked as well..
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Cookies and SOP (Score:2)
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).
Amazon Book Price (Score:2)
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.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
$48.10 from my regular browser, anonymous browser and IE.
public keys for hosts (Score:3)
(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".
Re: (Score:2)
How long... (Score:2)
I wonder how long it will be before Ristic is disappeared. My money's on 110 days.
Re: (Score:2)
Do you really think any government wants its citizens to have secure communication?
Encryption (Score:2)
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 resource
TLS/SSL/PKI is just the wrong algorithm. (Score:1)
For logging into a secure server the correct algoritmm is Secure Remote Password (SRP) [wikipedia.org].
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
This person should be banned from book reviews (Score:2)
"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.
Good read, really enjoying it. (Score:2)
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...
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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. Th
Re: (Score:3)
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
Re: (Score:2)
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 matt