Cenzic 232 Patent
Paid Advertising
web application security lab

Look for SSL, Stupid

I laughed when I saw a recent phishing email. Not so much because it was a new technique - it wasn’t. It was your old generic phishing scheme with SSL put in the middle of it: leo.ne.jp/ssl/onlinebanking.capitalone.com but it suddenly occurred to me. One thing I have heard many security people say when they are trying to explain best practices in web surfing to newbies is “look for SSL”. The term SSL means absolutely nothing to most people outside of the internet technology/security space. They may understand that “https” means it’s secure or that that “little lock thingy” in the corner makes them safe, but they don’t know why, and they probably have no clue that it’s SSL in the back end. So why do we tell them to look for it?

This all goes back to my distaste for consumer education. In this case our education is working wonderfully. The consumers are looking at that nice little “ssl” word and poof, they must be secure! They’ve never seen it before and they have no idea what it means, but they know that they’re secure now. I think it would behoove the security industry to stop chastizing people for being stupid when we are the ones who are misleading or miscommunicating to them in the first place. Besides, we need to come up with something more secure than SSL anyway.

Okay, new proposal time. Instead of inventing a new Internet (internet-s) with all it’s flaws, having to invent TCP and all the other madness all over again, what if we invent a new protocol that was still available to browsers, but lived in a far more restrictive sandbox? Why not make a new protocol that does what SSL was originally intended to do - secure people. No cross domain linking, no session riding, no anti-DNS pinning issues, no communication with browser shims or handlers, no XSS or JavaScript for that matter. Just a clean, well organized and most importantly a secured syntax that we can use for secure communication with servers. Why not? What we have now clearly isn’t working. I’m open to suggestions.

27 Responses to “Look for SSL, Stupid”

  1. Wladimir Palant Says:

    I think you will find this post interesting: http://blog.johnath.com/index.php/2007/03/21/revisiting-security-ui-part-2/

  2. Chris_B Says:

    rsnake, if that was supposed to be snark, it didnt come over very well. If you thought you were serious…..

    In any case educating the end users does help in my experience. However if they are taught wrong its not their fault.

  3. Jungsonn Says:

    TLS (transport layer security) is the thing you want.

    or IKE based IPsec, and L2TP (layer two tunneling protocol.)
    that are used in various situations.

  4. Alex Says:

    Well, that is exactly that what I’ve written here: http://www.bitsploit.de/archives/283-PC-WELT-Tipps-gegen-Phishing.html
    (sorry, only in German language)

    Trying to help people to understand SSL but making big mistakes at the same time.

  5. John @ NIST.org Says:

    I’ve seen phishing messages with real https links. When you go there its a self-signed certificate. Users don’t care, they’ve seen far to many legit sites with SSL error messages. They just click OK, get the little padlock thingy and they feel safe and secure.

  6. Andrew Says:

    @John - that’s exactly what I was thinking. A new, secure protocol is irrelevant if people don’t know how to reliably verify the identity of the server they’re conversing with.

    Do we need yet another certificate authority? Where does that leave the lower end sites that still require security but can’t afford to jump through the certification hoops?

  7. Awesome AnDrEw Says:

    @Wladimir
    While that’s a good approach we must remember that a majority of the demographic in question is less security or internet minded, and are less apt to be using FireFox. All of my co-workers are of much greater age, and some are under the impression AOL (which utilizes Internet Explorer of course) is protecting them with active virus, phishing, and spyware monitoring systems. I have a hard enough time trying to show family members only a few years older, or younger, how to do basic tasks and perform simple functions. If they’re not into the technological and security-wise aspects of computers they just won’t understand. We all have to realize that we are truly the few (percentage-wise compared to the overall internet community) that are more intelligent or knowledgeable in these areas, and would be over-estimating them by believing that implementing any new feature or protocol would be beneficial to the average user.

  8. c0ffee Says:

    “No cross domain linking, no session riding, no anti-DNS pinning issues, no communication with browser shims or handlers, no XSS or JavaScript for that matter. Just a clean, well organized and most importantly a secured syntax that we can use for secure communication with servers. Why not?”

    I really wish we could but the utopia (dystopia?) that is Web 2.0 or even basic web technologies we all love and hate would have to be discontinued. Legacy technology takes decades to get rid of once they are established and new unstandardized technologies can take over as the de facto standard when the install base is large enough (When was Internet Explorer standards compliant?) However I really digress.

    What is the problem with SSL? You are spot on. Most people have no idea how it works, what it is for, and what it means. They look for that little lock icon in the corner, if that.

    I don’t think the problem is so much in user education. After all, users have been educated to ignore all of the little grey boxes. Everywhere you look, in Windows especially, are little grey boxes giving you two options, OK or Cancel.

    Giving a user a dialog box with a title of “Website Certified by an Unknown Authority” and a bunch of technical jargon, three radio buttons about accepting or not accepting the certificate, a button allowing them to examine the certificate, and three other buttons at the bottom labeled “OK”, “Cancel”, and “Help”.

    There is nothing intuitive about this and without hours of research a non-techie would have no idea what any of this means and will just click OK like they did 100 times before that day.

    My proposed solution to the SSL issue (Not including all of the nightmare number of issues in browser/web sec) is present the user a big red screen on the web browser that says the following, “The website you are attempting to connect to has invalid SSL information and has been detected as potentially fraudulent. For your protection the web browser will not allow this web site to be opened.”

    If you want to add a protocol to that, perhaps the browser could be written to identify the web site owner to notify them that a self signed cert or and outdated cert is used on their site or one appearing to be originating from them.

    99.9 percent of users should probably not open sites with invalid certs and should just flat out be prevented from doing so. Yes this presents some problems such as corporate intranets where the admins should be adding the corporate CA as a trusted CA, and this will also cause an economic impact to sites that cannot afford a cert from a browser default CA, and on and on… but let the market figure that out.

    We know what these messages mean and ignore them every time we load up a web proxy to do our jobs, but I think this would simplify the problem very quickly for the normal end user and force web site admins to follow proper practices for SSL.

  9. RevShare Says:

    Jungsonn, TLS (and SSL, ipsek, l2tpetc) provide strong encryption for making sure that nobody is eavesdropping, or attempting middleman attacks (in some cases), But they don’t fix the real problem with phishing. Sure they might look for a valid certificate from a trusted domain, but in reality anyone can get those certificates. We need a system that has a manual certification process and is limited to certain companies.

    That problem is the user actually knowing they are at a site owned by who they think (bank etc). Anyone can setup an SSL server, and sure it means that people on the network can’t see your transactions, but as pointed out by RSnake, it means NOTHING about the authentication of the actual site. And anyone can get a certificate to validate that site, but that doesn’t validate that its the site that the user THINK’S it is.

    The first comment seems to be an attempt at coming up with a “trusted domain” marker, which is probably a good simple solution.
    It shows the general John Doe that this domain is trusted at a high level. Of course as already mentioned this means that you need an actual manual certification process where a human says - “yes this company is real and is large enough to get certification”.

    Just giving out certificates to whoever wants one means nothing if John Doe doesn’t realize that a certificate means “yes this website is certified to be paypal-renewals.com” (but not in anyway affiliated with the company PayPal)

    I guess we don’t need “yet another certificate authority” what we need are layers of certificates and visibility to the unknowing user.

  10. RSnake Says:

    @Wladimir Palant - I’ve looked into that type of security quite a few times. It’s only as good as people are willing to let it get before it gets so annoying they switch to another browser. The SSL lock isn’t cutting it, the green background URI field isn’t working either. So if I have to put up with a huge guy on my screen is that going to drive the point home? Maybe for some people, the rest of the people will be happy it’s not there on the phishing site. One less annoying thing to stop them from entering their username and password.

    @Chris_B - Sorry, I was in a bit of a hurry when I wrote it… It was a bit of a jab at people who preach security training as having any real value in large markets (snark intended). Sure, you training your friend is going to work, but putting online or inline training has been proven not to work in at least four different places that I am personally aware of, and I was involved in multi-million dollar trust and safety campaigns, nothing small-time. So, while your personal experience is interesting anecdotal evidence, it’s probably not relevant to what I’m talking about. As a side note, education is listed as one of the dumbest concepts in computer security. I happen to totally agree with this from all the large scale (million users or more) case studies I’ve been involved with: http://www.ranum.com/security/computer_security/editorials/dumb/index.html

    @Jungsonn - unfortunately that doesn’t really solve any of the issues I’ve talked about here, as that is seamless to the ways browsers work, and therefore the bad guys have no problems finding ways to con people out of their money regardless of what encryption XYZbank.com uses.

    @John - that’s a good point. Perhaps the new protocol cannot be visited unless the user types in the address by hand? I dunno, I’m just thinking out loud. I’d prefer if there was no way for the normal web to interact with it, because the normal web is highly insecure.

  11. RS Says:

    For me SSL was always “Supposedly Secure Layer”

    Many people look for SSL & HTTPS on the URL, but how many actually check the certificate

    In most of the cases I have seen people getting a feel god factor if they get an alert where either name date or CA of certificate is bad.
    The general response of people is click the [YES] button of IE & be happy that they are safe now as the site is on HTTPS

  12. hackathology Says:

    How about this SSL with SSH with strong ciphers? Anyway, just a thought. To invent something is a long proceess, why not incorporate what we have now into existing technologies? I really dunno, but as i said it is just a thought. Maybe the SSL developers can come up with something different in SSL v4. :)

  13. ChrisP Says:

    There’s no need to reinvent any transport-layer encryption. SSL, just like IPsec works just fine. What is not fine is the application riding on top of it, in this case HTTP (or “the web” in general). This is not a transport issue.

    Goes back to the argument you made about the OSI layer being obsolete: here’s a case where it helps to refer back to it ;) SSL can use the most recent cipher suites available - seriously, there is nothing wrong with it. It’s 100% user education. Your new protocol would have the exact same issues unless you fix the underlying issues at the app layer. Why would CSRF/XSS/etc go away with another secure transport?

  14. Kassad Says:

    I agree that the majority of the population will never attain the required knowledge to handle security issues, however you try to educate them.

    I have only a basic knowledge of the “workings” of the internet (being a ccna) but I think there will never ever be a real secure protocol. It follows from the nature of the “medium”.

    I only see a possible solution in mixing technologies, that is using e.g. mobile phone for secure indentification and approving transactions. It could use fingerprint tracking (right now, it is possible) later on dna identification. Even this could be tracked or manipulated but at least, it is a more controlled environment.

  15. Legionnaire Says:

    There’s no point in inventing a new “secure” protocol. Currently, SSL is secure enough (algorithmically). The problem comes when interfacing with the end-user. What RSnake said is true: there are so many expired or malformed certificates out there that most users have developed the habit of ignoring such warning messages. Security may be very well elevated by educating users in properly using the existing techniques. Otherwise, even if you come up with SecureProtocol2010, phishers will still find their way into users’ accounts. That’s because phishing is similar to “social engineering”, attacks of this kind do not target the protocol but the humans using it.

    Finally, a suggestion: here in Europe there’s European Computer Driving License (E.C.D.L.) which is a basic-computer-usage certification, valid across the EU. How about a similar basic-security-usage certificate? Sooner or later, an employer will require proof that a secretary opening an attachment or visiting a website won’t open a hole in the company’s expensive security perimeter.

  16. beaule Says:

    A few month ago, we face some security problems about the fact that SSL is an illusion of security…
    trojan, proxy,XSS, session hijacking, browser explorerbar, browser toolbar, browser extensions and many more…

    I think that SSL is secure but the browsers NOT…
    If a new browser (or the existing browsers) will switch AUTOMATICALLY(not with a user interaction) in a secure mode(more restrictive)
    which do not allow thinks like toolbar, extensions,…
    which alert a proxy usage,
    which avoid cookie access with javascript…(i know we can do it with IE)
    and many other patterns…

    maybe we can browse the internet and make money transactions more securely…

    Do you think that you will have discussions about
    —- for example:
    where can i hide my house keys when i have to go and my children need it?
    where can i hide my gold bar in my house? —-

    with your wife(probably safe :)) and some other people that you don’t heard about?

  17. FR3DC3RV Says:

    Some months ago i started developing a program that sends 128-bits encrypted messages from a computer to another, the main objective of the project was to emulate something like internet but without all that bugs. It’s stopped now because i ‘m learning OpenGL in C++ and i don’t have time.
    I hope to be able to restart programming it when i finish OpenGL.

  18. Chris Snyder Says:

    Seriously, how great would it be to have a simple way to tell the browser “you must sandbox this HTTPS resource and disable extensions when viewing it.” Manual confirmation would be required when accessing such a resource from outside of the domain to prevent XSS.

    It’s not a new protocol per se, but a new identifier associated with HTTPS. secure://accounts.example.com/

    Protocol identifiers are already associated with external programs, so secure:// urls could easily be made to open in a stripped-down, sandboxed browser.

  19. ChrisP Says:

    “How about a similar basic-security-usage certificate? Sooner or later, an employer will require proof that a secretary opening an attachment or visiting a website won’t open a hole in the company’s expensive security perimeter.” –> with HTTP/”the web” in its current form, that is impossible. Your browser executes javascript without warning you. If you turn it off you break a nice chunk of commercial sites. And that’s just the tip of the iceberg. I can embed a link to a XSS/CSRF vulnerable website inside an image. How do you explain this to your secretary?

  20. RSnake Says:

    @Chris Snyder - I think you are getting what I am saying.

    Most of you are talking about writing a new protocol with new forms of encryption (that’s not at all what I was getting at). I meant something closer to what Chris Snyder was saying (although his solution I think is probably more elegant that my original idea). But taking it out of the realm of where JavaScript can be injected into it (since it won’t work), taking it out of the realm of CSRF (since users would be warned if upon any transmission of data in or out of the sandbox) and removing all access to that sandbox by toolbars or anything else that has common vulnerabilities. Maybe there would be a way to turn off parameters to it as well, so even if you do link to it you can only link to the main page, removing parameter based CSRF. There would be little or no education involved.

    I’m trying to get a discussion started, I’m not saying this is the answer, but clearly what we have now isn’t working, and I think it’s unwise to blame the consumers (putting on my consumer advocacy hat again). It’s our fault that it’s built like this, and it’s our fault we haven’t come up with a solution.

  21. Legionnaire Says:

    @FR3DC3RV: Could you elaborate on your secure communication program? How does that emulate the Internet? Are you talking about something as low as OSI Layer 3 (Network Layer) or maybe OSI Layer 7 (Application)?

    @RSnake: An Internet Browser is a general-purpose program which should be able to support many different languages to achieve the desired functionality. Talking about sandboxes and stuff, you describe a “Secure Browser” which has nothing to do current implementations such as IE and Firefox. Should something like that be developed it might not even be called a browser but a “Secure Communication and E-Commerce Application”.

  22. jk Says:

    What if browsers forced more structure in HTML documents? For example, Javascipt code or links to JavaScript code can only appear in the HEAD section of a document. If the browsers sees it in the BODY section, it should be ignored. The only exceptions would be calls to functions in the JavaScript code. This would take care of most XSS. Am I missing something? Thoughts?

  23. FR3DC3RV Says:

    @Legionnaire:
    My program is still under development(5% already done,maybe.)
    Description:
    - It will work at OSI Layer 7.
    - It uses winsock to send encrypted (128 bits PC1 PUKALL CIPHER 1) packets beetween computers.
    (Not done)
    - It will have some language similiar to HTML and Javascript.
    - The server will encode the special chars from the user input before “reading” it.(trying to prevent XSS and SQL Injection)
    - For compatiblity reasons i may include an plug-in that transforms HTML code in “this program strange language”.

    I think that’s all but I guess that I will think of others as I start to work on it.

  24. beaule Says:

    @Chris Snyder I’m agree with you, that’s exactly what i think…

    But why do we need a new identifier???

    SSL means “secure” on the internet, so

    Each browser have to be be “sandboxed” for all HTTPS resource!!!

  25. Chris_B Says:

    @rsnake

    Kinda ironic for MJR to be quoted here, in this context, but anyways… This is an area where Marcus and I disagree, but I think its because security training up to now has approached from the wrong angle. It does no good to teach non technical users about technical measures to solve a problem that is not technical to begin with.

    SSL/TLS (or any other form of transport crypto) address the technical problem of privacy of communications but do nothing, and can not address, the greater social issue of trust. Volumes have been written on this matter, I wont try to summarize them here except to add my personal opinion that the commercial CAs are mostly a protection racket. As things stand now, certification is an unsolvable social problem on a global scale.

    To come back to user training though, think about this: people may or may not be born with an instinct to trust others, but they certainly learn alot about how and when to trust people, situations and places. In the real world as on the net, trust and threats are constantly changing; user training should as well.

  26. gk Says:

    The following idea is quite nice, although the implementation is really unpolished: http://www.cs.biu.ac.il/~herzbea//TrustBar/

  27. rugs Says:

    It all comes down to a person knowing what they are doing. There can be all kinds of safety protocols in place, and still a person can let it all fall apart if they are not sure of what they are doing. It is like a virus scan. It could be the newest and most updated version of it, and still a person can get a virus just by being stupid and not careful enough. There are a lot of people out there that do not know the ins and outs of the net and the programs that they use. So, it is not entirely the fault of programmers if things slip through the cracks. They can only do their best and hope that people properly use what they make. If they make a mistake, they can easily fix it and they are good at doing that. A program is only as smart as the person using it.