Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Books Security Book Reviews

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.
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.
This discussion has been archived. No new comments can be posted.

Book Review: Bulletproof SSL and TLS

Comments Filter:
  • 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.

    • 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.

    • 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.

    • by jandrese ( 485 )
      You've never tried to actually code to the SSL library have you? It's a poorly documented nightmare of parallel APIs full of pitfalls and crypto-nerd jargon. 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. It also has decades of old cruft in it that you shouldn't be using but the manual won't tell you which parts those are. Also, not everyone agrees as to what is the best way
      • You might think I'm exaggerating, but even major corporations fuck this up all of the time. There is no "just choose sensible defaults and give me a secure socket" call, because if there were someone would complain that it's not secure and shouldn't be used.

        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

    • 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.

  • 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.

    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

    • Well yes, you should use SSL. It may have problems, but what's your other option?
      • 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.

        • I remember back in 98 or so, Yahoo actually did do encryption in Javascript when they sent the password over the wire (for yahoo mail). I was impressed when I saw it. I suspect it had some kind of weakness, but I doubt anyone ever broke it.
        • by Gr8Apes ( 679165 )

          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.

    • by amorsen ( 7485 )

      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.

    • SSL can be insecure if used improperly, but if properly set up, it can be secure.

      Thank you

      Chewie, take the professor in the back and plug him into the hyperdrive!
    • 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.

    • 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/

  • by 0123456 ( 636235 ) on Monday November 24, 2014 @04:30PM (#48451701)

    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.

    • by ChadL ( 880878 ) *
      If a site sends a strict transport security header (e.g. "Strict-Transport-Security: max-age=31536000; includeSubDomains"), it will cause a browser to store that and refuse to allow an override if the certificate verification fails (and also changes plain http attempts to https). So for sites that do have certificates and wish to have enforcement of that there is a good option for that (though doesn't help for the first request, that is unlikely to have anything interesting in it).
      • by Shados ( 741919 )

        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

  • by Dr. Evil ( 3501 ) on Monday November 24, 2014 @04:31PM (#48451707)

    "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.

    • 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.

      • by Dr. Evil ( 3501 )

        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.

        • us-cert.gov doesn't give really give you enough info. Look here for a fix that fits within the protocol. [imperialviolet.org] No one wants to do any serious work on it though because SSL isn't worth it.
          • by Dr. Evil ( 3501 )

            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.

            • The compatibility problems mentioned are because of people not following the standard. They're not a problem with the standard itself.
      • It's a protocol problem if a man in the middle can control some bytes in the encrypted stream. The biggest problem with attempts to keep HTTP & SSL secure, is the combination of sensitive application and user supplied data sent over the same stream in both directions.
        • 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?

          • 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

  • by s.petry ( 762400 ) on Monday November 24, 2014 @04:44PM (#48451821)

    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.

    • 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.

      • by s.petry ( 762400 )
        This trend started last week when the system went into off line mode for several hours, so has little on the surface in common with long timers leaving.
        • Also, it seems I'm not getting email notifications when people reply to my comments anymore. I suspect that is related as well, both happened about the same time.
          • by s.petry ( 762400 )

            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..

          • Oh, so that's why I didn't see any responses for the last week, and then this morning just a huge flood of stuff to go through. Interesting data point: the only post of mine that kicked off a lot of replies despite the messaging bug was political.
    • I went several years without getting any mod points, then a few months ago started getting them again. Can't remember if I had any since the outage last week.
    • by Opyros ( 1153335 )
      I had mod points which were supposed to expire on the 20th, but in fact didn't expire until today! There is obviously a bug somewhere.
  • 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.

  • by fredan ( 54788 ) on Monday November 24, 2014 @04:58PM (#48451953) Homepage Journal

    (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 resource

  • 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

  • "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...

Remember to say hello to your bank teller.

Working...