Lindstrom on SSL

Dave G. | March 27th, 2007 | Filed Under: Industry Punditry

Pete Lindstrom muses about whether SSL has outlived its usefulness:

You know, at some point we should really re-evaluate the use of SSL in our Web architectures. Let’s face it, it hasn’t really done much for us:

1) Users read way too much into its functional value.

That’s true. But that is mostly because websites overhyped them. Also, I don’t think that user expectations is a good reason to get rid of one of the only security technologies that actually works to make transactions more secure on the Internet.

2) The threat model for sensitive Web data has never been one of sniffing traffic. There are still way too many accessible websites for this to be the case.

It is true that the primary means of sensitive web data theft has been through active attacks on websites rather than sniffing. Isn’t this where you thank SSL? Moving away from SSL just increases the odds that you are going to add sniffing back into the threat model.

3) If you are going to compromise some device, you might as well compromised the host and not some intermediate device.

Unless, of course, the intermediate device is less protected. Also, why should we trust every hop in between two hosts on the internet (any more than we have to).

4) The bad guys are now leveraging SSL more and more to shield their activities from good guy sniffers.

It is true that SSL can muck with IDSes. But ‘good guy sniffers’ are just one tool in the arsenal. SSL is another tool in that arsenal. In the rock-paper-scissors of security protections, I’d bet on SSL over IDS.

Quick reader poll: What are enterprises doing to detect attacks over SSL?

Viewing 25 Comments

    • ^
    • v
    Most people who do it terminate SSL at a load balancer type device then sniff the traffic between that and the actual web servers. I don't know as ingle person that actually uses the features in some IDS/IPS tools that allow you to import the SSL key and do decryption on the fly for analysis purposes.
    • ^
    • v
    Funny, I was just reminiscing about how my first online order was using CDNow via telnet in '94.

    But umm yeah, let's do away with SSL, because errr... online orders should still be plaintext! (??) And since he seems to think that we shouldn't be using passwords anymore (yeah, because even though tokens/SecureID/smartcards might be a sham in an enterprise environment, they're really really making inroads with amazon and myspace and gmail), that obviously means that we should also abandon SSL-VPN's as well. Heck, I'm with Lindstrom, just because bad-guys use something, we should stop using it! (See previous Linstrom-tyraids about vulnerability disclosure).

    Let's save ourselves some hassles (though probably not laughs) and predict what Lindstrom will say we don't need in the future, because bad guys are using the technology for evil:

    disassemblers (sure, it may be useful for reversing malware, but so many bad guys are using these for finding more vulnerabilities!)

    virtual machines (today they may seem like a cost saving device for enterprises, but thanks to nefarious Joanna Rutkowska-types, now they're just resevoirs for more problems!)

    ... (fill in your favourite security-ish tools, e.g. captchas, IPSec, ECC memory, encryption)
    ...

    knives?

    I dunno, I mean I know Lindstrom is great laughing stock, but this is getting to the point of beating a dead horse. I think in general, best practice is to ignore the trolls, even when they troll from their own website or blog instead of using classic trolling tactics. Pointing them out once or twice to illustrate that people should ignore them is fine I suppose. But seriously, I never ever ever would've heard of this dude if you guys hadn't mentioned him. He probably has much more of a following now. We don't need more Steve Gibsons in our industry, do they need our help in being created? (Same goes for Slashdot commenter quotes, geeze if I wanted to read the comments, I'd do it myself, hell I'd subscribe to slashdot's rss feed if I even wanted to get that far).

    And as far as IDS's+SSL, there are some which just mitm the sessions iirc (and expect that users are luddite enough to click through the warnings, because well, they generally do). Maybe people have more elegant solutions to that, I seem to remember Kaminsky proposing one at any rate.
    • ^
    • v
    We terminate incoming SSL on our IDS/IPS. We only terminate incoming connections where our SSL private key is used. Anything outgoing to an external site using SSL is not examined and anything incoming that is not recognized will just raise an alert for minor investigation.

    I wanna respond to Pete too!

    1) True, but that's not SSLs fault.

    2) I don't see why the fact that some websites don't use SSL is a reason to say the SSL threat model has never been about sniffing. Not everyone in my city locks their doors at night, so does that mean door locks are not about keeping someone out? But even assuming Pete is correct about it not being the threat model, just because a measure is stopping a particular behavior does not mean you can remove the stopping measures. I've never been physically broken into, so does that mean I can stop locking my door? (Of note, I expect to see this hypothesis from business-types more and more often as the years go by...)

    3) I admit, I'm not sure where he was going with this one...

    4) Fair enough, but again that's not the fault of SSL. If you take away SSL, the 'bad guys' will still obfuscate their own traffic.

    Now and then I sit at wireless hotspots with a coffee, a book, and my laptop open and just idly sniffing away. I'm quite happy if Pete wants to not use SSL anymore. He just better not log into anything or browse anything I might find interesting to learn about...not that I use that for nefarious purposes, but if I can do it, so can nefarious people. Those nefarious people can really fly under the radar by hijacking Pete's data and not risk the wide knowledge of a 500,000 person data breach.

    Attacking a web server to harvest data seems a very different attack than sniffing the wire, even really close to the target, to harvest a far smaller portion of data.
    • ^
    • v
    And by SSL attacks I was thinking you mean exfil over SSL or SSL encrypted botnet control channels (or other 'bad uses of ssl'). For that I suspect most folks arent' seeing them because their IDS's aren't looking for them :(
    • ^
    • v
    While I kind of agree with the points I *think* Lindstrom is trying to make (save for point 2 which is just silly), it’s not really clear to me that he understands the issues surrounding pervasive use of SSL/TLS. Probably next he, and the other *generalists*, will realize that it does not really even provide authentication and start arguing for something better (like SET); and we’ll have come full circle again.
    • ^
    • v
    Thomas:

    I think your question can be answered differently depending upon where the traffic originates -- inside or outside -- and the ultimate destination.

    Specifically, if the traffic is internal in origin and heading to the Internet, I think the answer is different than whether the origin is the Internet and heading toward a server on the DMZ...

    Solutions differ greatly for both.

    Chris
    • ^
    • v
    I am not the only person who writes here. =)
    • ^
    • v
    We've recommended IPS on both the inside and outside. You see much a lot of the stuff people are trying to do on the outside.

    SSL isn't really much different than other forms of DRM. It's really just a matter of time until it's cracked. Just look at HD-DVD and BluRay.
    • ^
    • v
    @Chris:

    Ok, answer for both :)
    • ^
    • v
    I hear DVD Jon's got a fast constant-time solve for factoring the product of two large primes. Just a matter of time before he posts it to Slashdot.
    • ^
    • v
    @Mitchel I wouldnt compare the protection SSL (or its cryptographic primitives) offer to DRM that comes with HD-DVD / BluRay. The strength of an SSL connection comes from the secrecy of your key (keys are obfuscated in DRM, they are not a secret to the attacker, unlike when your sniffing someones SSL connection) and the fact it takes an awful long time to factor large prime numbers.
    • ^
    • v
    If you never post again about Lindstrom, that will be too soon. Enough already.

    Also, in some cosmic coincidence, I just posted about SSL on my blog as an example of one of the few security systems with a mesh (vs. chain) model.
    • ^
    • v
    Dave,

    Everywhere I've worked it is terminate the inbound on a specialty device and then monitor the traffic.

    As far as Lindstrom goes, use the old maxim "Dont Feed The Trolls"
    • ^
    • v
    blah! what's all this nonsense about SSL outliving its usefulness??? The very same 4 clueless remarks can used to lead to an equally aberrant conclusion: We should just move on and build our security "architectures" without all that weird and hard-to-understand crypto shit that has not really lived up to all user's expectations and which is being actively used "in the wild" by the bad guys looking to enforce the security and privacy of their communications. Look, there are multiple reports of massive use of "cryptoware" in the wild and the ThreatCon has been steadily pegged at 13 (you're S.O.L.) for the past 18 months, so we MUST do something about this crypto problem.

    But more importantly, we should also stat by removing all traces of source code from our servers and workstations once we had our applications compiled and linked because...you know, the bad guys are also using THAT (they are reading source code and, god help us! using Google's codesearch!@) to find and exploit bugs. This enlightening piece of wisdom, coupled with grey's revolutionary proposal to stop using disassemblers will secure all of our precious data. Forever!
    • ^
    • v
    Isn't the obvious point here the fact that engineering an entirely new solution has to increase the likelihood of introducing more points of failure in the resulting implementations?

    As buggy as certain SSL implementations might be, are we really trusting anyone other than djb to write complex protocol implementations without exploitable bugs? How many protocol implementations have been written in the past without some sort of exploitable vulnerability?

    New protocol implementations are rarely a good thing, except out of neccessity. How many vulnerabilities have been introduced into other protocol implementations because new features were added or protocols were replaced with others, Telnet, DNS, SMTP, HTTP, SSL, FTP, SSH, SFTP, and practically every other protocol in existence. The only time you ever re-engineer a standardized protocol is if you can guarantee that you are not only making it more functionally efficient, but are also reducing its overall attack surface.

    As far as I'm concerned as long as Joe Q. Dickless can't DNS spoof https://www.mybank.com/ and issue a matching trusted cert back to my client, or break the encryption of the session (in a meaningful amount of time); why would I ever want to replace the standard?
    • ^
    • v
    And Dave, to answer your poll question, my guess is a few of the IPS solutions out there are using protocol anomoly detection to catch funky values in protocol headers. Whether they're doing this with SSL or not, I couldn't tell you; although I really don't see any reason why the concept wouldn't apply as easily to SSL as it does to lower level protocols that are already being inspected.

    As far as I can tell, however, there is virtually no way for an inline IDS/IPS that has access to the session traffic to tell whether or not the client endpoint is being MITM'ed along the way without some sort of timing analysis where you compare the amount of time it takes to get responses for the session requests, and the actual transfer time of packets between the IPS device and the client, factoring in the difference of the IPS device to the server. If it takes substantially longer for the responses to come back you can probably infer there's a likelihood that a false cert is being issued by the apparent client, being decrypted, re-encrypted, passed to a client for processing and having the process repeated before the response is sent back to the server.
    • ^
    • v
    John, I don't think this is about designing new crypto protocols and whether that's risky or not. SSL3 is probably the best secure transport designed to date.
    • ^
    • v
    "Back in the day", sniffed passwords from telnet connections use to be a common attack vector. Then along came secure shell. Believe it or not, ssh wasn't an instant fix to the problem. I could go into the various ways that ssh wasn't implemented properly and attackers where still abusing account information (ie: telneting to your "ssh system" isn't a good idea). From an intrusion analyst/incident response guy's perscpective, I hated seeing attackers control channels move from telnet to ssh. Don't blame the transport, blame the implementation.

    Anyway, I think you can legitmately compare the HTTP/HTTPS debate with telnet/ssh. I don't think you'll find anyone saying we should go back to telnet, just because attackers are able to use ssh too.

    Someone kicked my dog Mavis and I am going to find out just who the hell it was...I am all hyped up on cough syrup^H^H^H^H^HPercocet right night, so just like, nevermind.
    • ^
    • v
    Tom, I was under the impression that if Lindstrom wanted SSL to go away, that he intended to replace it with something. The idea of completely doing away with session encryption in web architectures because endpoint security is not up to snuff is, well, retarded.

    Unless SSL implementations are increasing the attack surface of your web architecture to an extent that the endpoint encryption they provide becomes useless, you have to say it's doing more harm than good to remove it.

    I don't see how any sane thinking individual could think otherwise.

    Security, to me, is about not only striving to make application resources impenetrable, but also whenever possible producing designs that (while remaining functionally efficient) reduce the opportunity cost of exploiting the architecture. Because even if exploits for a protocol implementation are created, if too much effort is required to produce them (and subsequently the value of finding the bug and writing the exploit fails to outweigh the value of the exploit's usefullness), the security community still wins.

    Maybe I'm still looking at this the wrong way though?
    • ^
    • v
    Jon, you got it right the first time -- it's retarded. So bug Matasano never to mention the L-name again and let's get back to work.
    • ^
    • v
    @ Nate et. al:

    In response to your blog bullying, I have decided that April is going to be Month Of Lindstrom Posts. MoLP will feature posts containing multiple links to Pete's posts, and will feature in depth analysis about every statement he makes, including all posssible inferences.
    • ^
    • v
    Oh god I hope you are serious. THAT would be entertaining.
    • ^
    • v
    Wow, well count me in for the 'that is a really silly idea' vote. It should be noted though that most of the data theft taking place out there in terms of transactions *is* being done either by hooking the keyboard (or something circa) on an infected system or by logging incoming transaction on an owned up server. The man in the middle attacks cost more and are less effective. Of course if it plain text (wow, that really is a BAD idea) I am sure you would start to see more of them.

    -al
    • ^
    • v
    I'm remembering something about a whole ISP being sniffed with SunSniff back in the mid-90's. A couple thousand accounts cracked. Where did I hear about that? OH YEAH, I WAS THERE.

    But yeah, I get the argument. Attacks that were spectacularly successful in the 90's are "played out", so attackers would be too bored to use them.
    • ^
    • v
    (I'm agreeing with Al, btw).

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus