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.

Comments

It's an encryption layer

[i kan reed]

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:It's an encryption layer

[schneidafunk]

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:It's an encryption layer

[nine-times]

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:It's an encryption layer

[Anonymous Coward]

I can see reading a 530 page book on it. Look at some of the online examples. One of my favorites was "I was having problems getting the certs to verify properly, so I just didn't". Yeah, for somebody securing their site with SSL, and then feeling they'd done a good enough job with it to write a tutorial, and have that line in it. Good god.

Re:It's an encryption layer

[Anonymous Coward]

I just set one up right now. Easy stuff.

What I'm wondering is who has the perception that a website is indeed secure if it is SSL secure.

Re:It's an encryption layer

[Anonymous Coward]

the review linked to the table of contents here: https://www.feistyduck.com/books/bulletproof-ssl-and-tls/bulletproof-ssl-and-tls-introduction.pdf

if you look at it...there is a lot of information there.

Re:It's an encryption layer

[Anonymous Coward]

It's meant to be simple middleware in network communication: almost transparent to applications, and with only a little system setup, like certs.

Exactly. The purpose of TLS is to deploy secure cyphers. If TLS can't do this out-of-the-box (or minimal setup, like removing insecure ciphers from acceptance list), then the protocol is broken.

I mean, how hard is it to provide an interface for DH/EC + symetric ciphers + certificates for verification of DH/EC handshake? Why do you need 500 page book when you are not making new protocols, just deploying something security experts already deem secure?

500 page book is what you need to design your own secure protocol out of primitives, like SHA256, ECDH, and Salsa20. Or if you plan on implementing these things, you really need this too.

And if you want to design your own stream ciphers, you probably need more than a 500 page book and a degree in Math and information theory. You probably want a job with people around you working on same things.

But for deployers? Really? You only need to know how TLS works and how to configure it, not how OpenSSL innards work. Even for developers, you should not be implementing this stuff yourself anyway. Use a commonly used OSS library for this, not OpenSSL directly, if possible (not the ciphers!)

Re:It's an encryption layer

[jandrese]

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 to use it. I'm sure someone will come out and complain that the suggested techniques in this book leave you vulnerable to some kind of weird side channel attack in certain circumstances and that you should do it a different way instead, a way that this author thinks will open you up to some other kind of attack.

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.

Re:It's an encryption layer

[petermgreen]

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.

Re:It's an encryption layer

[IamTheRealMike]

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.getInputStream(); // read stream here ....

That'll do the right thing by default.

SSL is imperfect, but that's because crypto is hard, not because of some fundamental fuckup somewhere and if only we all used the alternative protocols (which?) everything would be peachy.

Re:It's an encryption layer

[Anonymous Coward]

Which CAs were those certs checked against? Were the intermediaries properly sent back by the server? Has your connection confidentiality been defeated by a downgrade attack?

Re:It's an encryption layer

[Anonymous Coward]

It's an encryption and authentication system. The encryption part involves a cipher negotiation. The authentication part replies on finding a third-party who has vouched for one endpoint.

The cipher negotiation is complex because the weak ciphers might as well be replaced with transmitting in plain text, and an adversary is capable of fooling the two end points into using one of these or terminating the connections.

The vouching system is complex because it is hard to know which CAs to trust. It is further complicated by validity dates, different signature algorithms, certificate chains, cross-signing, revocation, and too-small roots.

Re:It's an encryption layer

[jandrese]

Those are all concerns you shouldn't have to worry about in a proper API. It should do those checks for you and return an error if something doesn't look right.

Re:It's an encryption layer

[Anonymous Coward]

Something "not looking right" is highly dependent on the context. As a simple example, there is no one right answer for the list of CAs to trust.

For each of the others you are looking at confidentiality/availability trade-offs. Sometimes the trade-offs lock you off from big chunks of the internet. For example if a particular cipher isn't available on 5% of your customer's computers, should you support the bad cipher that they can use? What does that do to the safety of your other customers?

If this were easy, there NACL and its ilk wouldn't exist. The best I can do is to remind people that it is not simple. This isn't just a case of needing to tweak an API. You can't just "add security" to something. Heck, you can't usually even "add encryption" and get the result you expect. If you want to use any of this stuff safely, your only recourse is to educate yourself.

So is that a yes or a no?

[ArcadeMan]

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?

Re:So is that a yes or a no?

[nine-times]

Well yes, you should use SSL. It may have problems, but what's your other option?

Re:So is that a yes or a no?

[i kan reed]

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:So is that a yes or a no?

[amorsen]

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:So is that a yes or a no?

[phantomfive]

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.

Re:So is that a yes or a no?

[Gr8Apes]

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:So is that a yes or a no?

[i kan reed]

Zero traffic means zero traffic interceptions.

Re:So is that a yes or a no?

[freeze128]

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!

Re:So is that a yes or a no?

[Gr8Apes]

But someone is using it, so traffic is not 0. And installed means potential security hole.

Re:So is that a yes or a no?

[benrothke]

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:So is that a yes or a no?

[petermgreen]

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)

Certificate warnings

[0123456]

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:Certificate warnings

[ChadL]

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

Re:Certificate warnings

[Shados]

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're looking for).

I have learnt something useful on slashdot today. Holy crap.

SSL?

[Dr. Evil]

"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:SSL?

[phantomfive]

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:SSL?

[Dr. Evil]

POODLE is not an implementation problem. It's a protocol problem.

https://www.us-cert.gov/ncas/alerts/TA14-290A

"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:SSL?

[complete loony]

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.

Re:SSL?

[phantomfive]

us-cert.gov doesn't give really give you enough info. Look here for a fix that fits within the protocol. No one wants to do any serious work on it though because SSL isn't worth it.

Re:SSL?

[Dr. Evil]

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

Re:SSL?

[phantomfive]

The compatibility problems mentioned are because of people not following the standard. They're not a problem with the standard itself.

Re:SSL?

[phantomfive]

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:SSL?

[complete loony]

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 HTTP & SSL, not on SSL alone.

HEY DICE, WHAT THE FUCKHAPPENED TO MODERATING?

[s.petry]

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.

Re:HEY DICE, WHAT THE FUCKHAPPENED TO MODERATING?

[DigitAl56K]

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:HEY DICE, WHAT THE FUCKHAPPENED TO MODERATING?

[s.petry]

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.

Re:HEY DICE, WHAT THE FUCKHAPPENED TO MODERATING?

[Anonymous Coward]

Nigger shut your mouth

Re:HEY DICE, WHAT THE FUCKHAPPENED TO MODERATING?

[phantomfive]

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.

Re:HEY DICE, WHAT THE FUCKHAPPENED TO MODERATING?

[s.petry]

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:HEY DICE, WHAT THE FUCKHAPPENED TO MODERATING?

[phantomfive]

Oh, yeah, I just got emails from all my responses for the last week.

Re:HEY DICE, WHAT THE FUCKHAPPENED TO MODERATING?

[MyFirstNameIsPaul]

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.

Re:HEY DICE, WHAT THE FUCKHAPPENED TO MODERATING?

[Opyros]

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.

Re:HEY DICE, WHAT THE FUCKHAPPENED TO MODERATING?

[Anonymous Coward]

Yes, and there's no HTTPS with STS security.

There's TorBrowser censorship.

It stinks like a NSA honeypot or something. oups - did i say that out loud

Re:HEY DICE, WHAT THE FUCKHAPPENED TO MODERATING?

[meustrus]

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.

SSL is dead

[Anonymous Coward]

welcome to 2008.

Re:SSL is dead

[Anonymous Coward]

So why then do over 150,000,000 sites use SSL if its dead?

Re: SSL is dead

[Anonymous Coward]

The Certified Dead perhaps?

Re:SSL is dead

[Anonymous Coward]

lazy or ignorant admins. maybe both.

Cookies and SOP

[MobyDisk]

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

[psergiu]

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:Amazon Book Price

[dumfrac]

$48.10 for me.

Re:Amazon Book Price

[gerald.edward.butler]

Same here: $48.10 - that's with Amazon Prime and through the "AmazonSmile" link (where it donates a portion to your chosen charity).

Re:Amazon Book Price

[Anonymous Coward]

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.

$742.59 for me.

Re:Amazon Book Price

[Anonymous Coward]

I got the same price.
There are used version for a bit cheaper.

Re:Amazon Book Price

[jtownatpunk.net]

$48.10 from my regular browser, anonymous browser and IE.

Re: Amazon Book Price

[Anonymous Coward]

How ya doing down under, Bruce?

public keys for hosts

[fredan]

(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:public keys for hosts

[Anonymous Coward]

So you are working on DANE?

http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities

Re:public keys for hosts

[Anonymous Coward]

that was replaced by great dane!

Re:public keys for hosts

[fredan]

No.

whitehat

[Anonymous Coward]

inventing whacky ways to bypass ssl
like breaking into a car assuming the only protection is keys kept under a funny looking rock

Re:whitehat

[Anonymous Coward]

no way...that is soooooooo black hat!

How long...

[jtownatpunk.net]

I wonder how long it will be before Ristic is disappeared. My money's on 110 days.

Re:How long...

[Anonymous Coward]

what is that supposed to mean?

Re:How long...

[Anonymous Coward]

I think it means he is off his meds.

Re:How long...

[jtownatpunk.net]

Do you really think any government wants its citizens to have secure communication?

Re:Secure Your Anus... GayWAD is Recruiting!

[Anonymous Coward]

u r an angry person....

Encryption

[davidwr]

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.

TLS/SSL/PKI is just the wrong algorithm.

[aberglas]

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

This person should be banned from book reviews

[mcmonkey]

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

Re:This person should be banned from book reviews

[Anonymous Coward]

OMG!!!! this is terrible.

i think its good u freaked out. i need xanax now.

Re:This person should be banned from book reviews

[Anonymous Coward]

i never heard the story...but if u go to http://en.wikipedia.org/wiki/The_Emperor%27s_New_Clothes
it is all a fable, fiction.

so whats the big deal?

Good read, really enjoying it.

[motorsabbath]

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

It's not only SSL/TLS

[Anonymous Coward]

TLS has problems of its own (which are of course much worse in SSL,) and the CA mechanism would work acceptably if CAs did their jobs diligently (which they don't all the time.) The elephant in the room is, of course, OpenSSL: a library with documentation that is worth than useless, with an implementation riddle with bugs, with a code that seems to have been developed by a bunch of clowns, and an API which seems to have been designed to make things as complex as possible for application programmers. It is an unsettling fact that the security of the Internet rests, to a very large extent, on this piece of crap.

Re:It's not only SSL/TLS

[Anonymous Coward]

ok that may be tru. but its all we got. u got something better than tls? try deploying it.

Re:It's not only SSL/TLS

[petermgreen]

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:It's not only SSL/TLS

[IamTheRealMike]

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:It's not only SSL/TLS

[petermgreen]

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.

SSL TLS good enough

[Anonymous Coward]

They're good enough solutions. Nothing is 100% secure. The point is you basically want any person with just a sniffer to have a hard time.

Re:SSL TLS good enough

[Anonymous Coward]

thanks!!! u must be bruce schnier!

Really?

[Anonymous Coward]

> Ristic writes that if you receive an alert about an invalid TLS certificate, the right thing to do is immediately abandon the connection attempt.

I'm sorry, but this is BS. It's only true if you're trying to visit something really security-sensitive. But there are loads of websites (incorrectly) using HTTPS that don't handle your credit card data, don't ask you for credentials etc. We should concentrate on educating Web designers to only use HTTPS when it's really appropriate and necessary.

Re:Really?

[Anonymous Coward]

if its an invalid cert...isnt that a cause for concern?

why risk it?

Re:Really?

[Anonymous Coward]

I'd enter a pr0n site with an invalid certificate every day of the year, provided that it doesn't ask for my credit card data.

Re:Really?

[meustrus]

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

Re:Really?

[meustrus]

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

48.00 too much

[Anonymous Coward]

I'd pay a dime for sure, and so would most here. Imagine selling out in a day, certainly do it before this like so many books like it goes beyond the realms of death! Do It! Do It! Do It! So, yes, better by you, better than me.