TLS and SSL in the real world
Quite a bit has been written about the Secure Sockets Layer (SSL) protocol and its successor Transport Layer Security (TLS), so I won't cover the protocols in detail here. The following are good references if you want to get a quick refresher.
Happily, a majority of web users now know to look for the lock icon and the HTTPS in the address line to identify when their connection is secure. Unfortunately, relatively few users understand what security guarantees these protocols provide. Fewer still understand the critical importance of digital certificates to secure connections. In a recent phishing attack, the bad guy used a third-party SSL-hosting server to display the lock icon for his fake banking site. Was the connection secure? Sure. Was it safe? Of course not.
Improving the user-experience around TLS/SSL is a significant challenge: how much can we help the user stay safe without having to explain all this mumbo-jumbo? Or should we try to explain public key cryptography, symmetric key exchange, digital certificates, the role of certification authorities, and more?
All the average user wants to know is: "Will my transaction be safe?"
Here we run into Law of Security #10-- Technology is not a panacea, and TLS/SSL alone can't answer the user's question.
It's easy to fall into the trap of assuming that spoofing fraud only occurs on the web, but there are plenty of "real-world" attacks that work essentially the same way. Examples range from a cashier using a hacked terminal to swipe your credit card, to the ambitious crooks who deployed a phony ATM in a shopping mall to collect card numbers and PIN codes. When was the last time you looked at your ATM and asked it for some ID?
Just because there are no simple solutions doesn't mean we're not working hard on making surfing more Trustworthy, and TLS/SSL will be a part of that. We're doing some interesting work here, which I'll be able to blog about at a later date.
For now, I'd like to point out that security is only as strong as its weakest link. To that end, I want to highlight two very common web-developer mistakes when building TLS/SSL web applications.
Critical Mistake #1: Non-HTTPS Login pages (even if submitting to a HTTPS page).
Most webdevs know that HTTPS is comparatively expensive-- the multistage handshake with multiple roundtrips and cryptographic operations is inherently less performant than straight HTTP. A few years ago, someone got the bright idea that login pages should be served via HTTP to reduce this performance hit.
The thinking goes something like: "Well, since the HTTP POST containing the user's credentials is sent via HTTPS, any man-in-the-middle can't see the data."
And this seemed like a reasonable idea. The practice became even more popular as banks and credit card companies decided that customers should be able to log in directly from the HTTP-delivered homepage. Three of my financial institutions offer this "convenience". One of them even draws little lock icons near the login box and provides a phone number for customers to call so they can convince them that it's safe.
There are two problems with this practice: One fairly obvious, and one slightly less obvious. The first problem is simple: How does the user know that the form is being submitted via HTTPS? Most browsers have no such UI cue. (Pretty much everyone turns off the "Warn when sending unencrypted form data" option within 2 minutes of installing the browser.) Even supposing there was a UI cue that the form was targeted at a HTTPS page, how could the user know that it was going to the right HTTPS page? If the login form was delivered via HTTP, there's no guarantee it hasn't been changed between the server and the client. A bad guy sitting on the wire between the two could simply retarget the POST to submit to a HTTPS site that he controls. Oops.
Think that's bad? There's an even more sneaky attack the bad guy could execute. The event model in HTML is pretty rich, and one of the things it can do is listen for keystroke events. So, the bad guy could simply rewrite the login page HTML to leak keystrokes to a server he controls, every time a key is pressed. Unsecured login form + Man-in-the-Middle+ 5 lines of JScript + Serverside keystroke collector = Bad News.
(Food for thought: The keystroke-sniffing attack gets even worse if your JS can run in the browser chrome, a feature offered by some browsers.)
Critical Mistake #2: Mixing HTTP Content into a HTTPS page
Some HTTPS pages pull in assorted resources over HTTP, which leads to the annoying "This page contains both secure and nonsecure items" prompt. Why does this hassle exist? Is it really so bad if some files get pulled down via HTTP, if the main body of my page is delivered via HTTPS?
The answer is, of course, yes, this is a bad thing. For one thing, it's impossible for the user to tell what parts of the page were delivered securely, and what parts were not. And worse, if a man-in-the-middle can rewrite the HTTP traffic, he can, for instance, rewrite the HTTPS page using standard DHTML. Or, he can scan the page for any information of interest (e.g. a credit card number) and POST that data to a server he controls. Using HTTP-delivered resources on a HTTPS-delivered page pokes holes in your secure channel. Don't do it.
What can we do today?
I hope you will join me in calling on operators of insecure HTTPS sites to correct these mistakes.
In the short term, you may be able to work around these security holes:
- If available, a "Login securely" link might lead to get to an HTTPS login form you can use instead of the form on a HTTP page. Or try visiting the https:// version of the site directly.
- If prompted to download mixed content, always choose "No".
Thought for the week
The so-called "browser wars" have fundamentally changed. It's no longer Microsoft vs. Mozilla vs. Opera et all. Now it's the "good guys" vs. the "bad guys." The "bad guys" are the phishers, malware distributors, and other miscellaneous crooks looking for a quick score at the expense of the browsing public.
We're all in this together.
-Eric Lawrence
edit: refer to the blog post titled: SSL, TLS and a little Active X: How IE7 Strikes a Balance Between Security and Compatiblity for updated behavior
Comments
Anonymous
January 01, 2003
Great article. It is a shame that there is little protection for the novice internet user against phishing whatever browser they are using; especially with the social scams such as use of international domain names to spoof proper domains.Anonymous
January 01, 2003
What are some examples of browsers you are referencing with your food for thought? The only browsers I know that run JavaScript in the UI are Mozilla-derivatives and there was an issue along those lines disclosed recently that affects them, but such issues I found are reportedly fixed in the latest Firefox release.Anonymous
January 01, 2003
Great article is this.
Thankfully, my bank was offering the 'convenient' way to login but then they replaced the login form with a big button which takes you to secure login page. I hope more banks and sites will follow.
I think it would be nice if this article was published on MSDN. So that a developer working for a bank website can go to Manager and show that Microsoft recommends not to have login form on non secure page. [Ofcourse this is for the managers who don't have clue... and they are in majority! :(]
JDAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
One of the features I like most about Opera is that on a SSL secured site it displays the company name that owns the SSL certificate in the address bar so you can tell if it is who it should be. And it's unobtrusive.Anonymous
January 01, 2003
"(Food for thought: The keystroke-sniffing attack gets even worse if your JS can run in the browser chrome, a feature offered by some browsers.)"
How is that different from a browser helper object in IE which of course has access to DHTML events?Anonymous
January 01, 2003
Chris Griego,
Because such visual cues as you describe inside the content area of the browser can be easily spoofed.Anonymous
January 01, 2003
Nice article, you brought up some points I hadn't really thought about before, namely the fact that a form that's being sent unsecured to a client could be modified by a man-in-the-middle attack.
However, if I was the attacker, and I was able to perform a man-in-the-middle attack on requests between the client and server, I would take advantage of the fact that most users just type "www.mybank.com" into their browser instead of the full "https://www.mybank.com". So right there, since the initial request is unsecured, I'd just modify the link to the secured login page and point it somewhere else... like to my own 'secured login page', which is similar to the point you made about modifying an unsecured form POST target.Anonymous
January 01, 2003
<<How is that different from a browser helper object in IE which of course has access to DHTML events?>>
It's essentially no different at all.
The general point is that enabling powerful browser extensions without introducing privacy/security holes is hard-- Regardless of whether or not you're using native code or script.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Critical Mistake #1: Non-HTTPS Login pages (even if submitting to a HTTPS page).
You're absolutely correct.
Why are there plenty of such pages to login to Passport used on the MSN site then ?Anonymous
January 01, 2003
Eric, this is a very useful and informitive article! More like this please...Anonymous
January 01, 2003
Nice article, thanks a lot ;)Anonymous
January 01, 2003
I found this very informative and interesting.
Provides some food for thought.Anonymous
January 01, 2003
At the end of a post on SSL/TLS and just how much security a "secure" site really gives you, Eric Lawrence of IEBlog posted an interesting thought:
The so-called "browser wars" have fundamentally changed. It's no longer Microsoft vs. Mozilla vs. Op...Anonymous
January 01, 2003
<<You say a majority of users [know to look for the lock but I don't believe this.>>
My statement was a bit ambiguous, so I should clarify.
In usability testing, when we ask users "Do you think this page secure?", a majority of users do know to look for the lock and/or the HTTPS.
That doesn't mean, however, that 50%+ of web users are ~routinely~ looking for the lock as they surf around the web.
I suspect you're correct in noting that many many users give no regular thought to the security of their web transactions.
The percentage who do take note of SSL will probably continue to gradually increase, particularly as more and more news about Internet-based scams make the mainstream press.Anonymous
January 01, 2003
Even the passport.net site itself uses an http login page when you click in the login buttons....Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
If the status bar is a bad idea, how about modify the frame around a web page? Unsecure sites would be normal, but you could have say a red or gold ring around a site that is completely secure. A mixed environment could have a completely different color, like half red half gold to say that part of it is secure, but because it's mixed the red says stop.
Of course I don't know how particularly easy this is, but it should be something that is easy to notice and can't be taken away by View > Status Bar. I do think that what we have has been sufficient so far, but take it a little step further for those of us not quite as fortunate to remember the umpteen steps we need to make sure a connection is secure. (It's not umpteen, but it's definately not one and seems to be getting more complex, not less)Anonymous
January 01, 2003
Jeremy: Unfortunately, that's easily spoofed, with something like:
body { border: 2px solid red; }
in your CSS file.Anonymous
January 01, 2003
Regarding the "This page contains both secure and nonsecure content":
If you dynamically push Internet Explorer a PDF as a result of a POST via https, you get this warning (even though the resulting page and everything associated with it is being requested over https).
Please fix this. The fix you've already provided:
http://support.microsoft.com/?kbid=321532
requires a web server to send Accept-Ranges: bytes in the header, which isn't a requirement of HTTP/1.1:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
"Origin servers that accept byte-range requests MAY send
Accept-Ranges: bytes
but are not required to do so."
If you really stand behind your article, you would help correct the problem of IE incorrectly showing this message when being sent a PDF file as a result of a POST.Anonymous
January 01, 2003
<<If you dynamically push Internet Explorer a PDF as a result of a POST via https, you get this warning >>
Have you installed the v7.0 PDF reader? I believe this issue was resolved.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
I don't buy it. Not that you're wrong; you're quite right. The problem is that if we assume the attacker can arbitrariliy get at the http stream and modify it. Assuming that capability, I ask you how the user gets to the https login page...likely from an http page...so that link is vulnerable to rewriting to a different server. For that matter, the user never even gets to your homepage, they go instantly straight to an imposter site.
This is assuming that the user doesn't, by themselves, unprompted, type in https://www.yoursite.com. If you link to it anywhere, then there's a vulnerable link in the chain. And very few businesses are going to accept requriing customers to type in the URL, remembering the https. I'd venture to say none.
I think it's safer to just say the whole https security model is nothing but window dressing anyway, so I'd hardly call these peices critical mistakes. It's too confusing for the casual user to figure out all of this out, so they punt; either by not participating or by not worrying about it. Not sure what the fix is.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
"The so-called 'browser wars' have undamentally changed... Now it's the 'good guys' vs. the 'bad guys.'"
Actually, its always been the 'good guys' vs. the 'bad guys,' only now Microsoft decided they want to be one of the good guys. We're still seeing how that's going to work out, because it seems that <a href="http://www.ivor.it/goog/big1000/">MSN Search favors IIS hosts</a>. If that doesn't fall under 'looking for a quick score at the expense of the browsing public', I don't know what does. History has shown that Microsoft thinks nothing of poisoning its relationship with the internet community, and that continues to be the case.Anonymous
January 01, 2003
With regards to "Mixed content" error:
It makes sense to display such a warning if a page includes insecure content that may contain damaging client script. That would include <script> <object> and <applet>, perhaps <link> (CSS), and perhaps <frame> and <iframe> (see below).
It does NOT make sense to display such a message for pages that include insecure images <img>. Why would you want to pull a bunch of GIFS and JPEGS thru SSL. That causes completely unecessary server load and client slowness (especially because SSL served images generally won't get cached).
Not displaying the error message for insecure <img> URLs is a simple fix.
Perhaps better than an error message would be to refuse loading the dangerous tags <script> <object> <applet> if not served via SSL (on the same domain).
Frames <frame> <iframe> can be sandboxed (a feature added to HTA's in IE 6.0, such that they can't get access to the containing document.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
I disagree regarding images. An insecure image request could get re-routed to a malicious server, serving up images that trigger various overflow bugs in image loading code (of which there have been at least a few in all browsers), and take control of at least the browser.
If they are ssl, at least you know they haven't been tampered with on the way, and the original end point is the server that you looked at the cert for and decided to trust.Anonymous
January 01, 2003
www.cn-apple.comAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
You know what would be nice as well?
It would be nice if you could somehow extend
the SSL/TLS spec to allow operators to relax
the need to have unique IP's for each domain.
This would allow hosting providers to host
multiple certificates on a single web server
IP. (Like non-ssl)
I mean, is it such a leak that I'm talking to a
particular host if I have that IP address?Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Re: using a single IP for multiple SSL Host, you want Server Name Indication.
Look at https://sni.corelands.com/ for more info.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
April 20, 2006
PingBack from http://antbsd.twbbs.org/~ant/wordpress/?p=115Anonymous
April 25, 2006
Today, Microsoft released Internet Explorer 7 Beta 2. I recommend you to download it in order to test...Anonymous
June 02, 2006
The comment has been removedAnonymous
July 27, 2006
PingBack from http://dclub5.com/blog/?p=3Anonymous
October 19, 2006
IE7 was released yesterday. If you're a web site owner, developer or designer, and find that your site or application is encountering problems, fret not. Here is a list of resources for you: Read the Checklists Download the IE7 Readiness...Anonymous
October 19, 2006
IE7 was released yesterday. If you’re a web site owner, developer or designer, and find that your site or application is encountering problems, fret not. Here is a list of resources for you: 1. Checklists 2. Download the IE7...Anonymous
October 19, 2006
From now on, we have to test our web application on another version of browser. Source: http://dotnet.csdn.net/n/20061019/96467.html Microsoft IE7已于今日正式发布。微软在网站上公布了开发者和Web制作人员要注意的一些事项。翻译如下： 确认你的程序中关