Slashdot Mirror
Internet Explorer 11 Gains HTTP Strict Transport Security In Windows 7 and 8.1
Mark Wilson writes: Anyone using the Windows 10 preview has had a chance to use the HTTP Strict Transport Security (HSTS) in Microsoft Edge, and today the security feature comes to Internet Explorer 11 in Windows 7 and Windows 8.1. This security protocol protects against man-in-the-middle attacks and is being delivered to users of older version of Windows through an update in the form of KB 3058515.
You'll be safe. Trust Microsoft. They know about security. When they promise it, they promise it.
Seven puppies were harmed during the making of this post.
I, for one, welcome this change to Internet Explorer. Now, I can know I am truly safe from man-in-the-middle attacks the next time I load a fresh Windows install and open IE10 so I can download Firefox.
looks like internet explorer is behind
From wikipedia:
Browser support[edit]
Chromium and Google Chrome since version 4.0.211.0[28][29]
Firefox since version 4;[30] with Firefox 17, Mozilla integrates a list of websites supporting HSTS.[20]
Opera since version 12[31]
Safari as of OS X Mavericks[32]
Internet Explorer 11 on Windows 8.1 and Windows 7 since June 2015[33]
Microsoft Edge and Internet Explorer 11 on Windows 10 Technical Preview support HSTS.[34][35]
keep them doggies Edgin', IE!
Comment removed based on user account deletion
Oh great, MS finally woke up and implemented what everyone else already had at the very least a year ago.
Also how low has Slashdot fallen that we now qualify MS getting something that everyone else already has as "news"?
Yes, they really think they can protect against an MiTM attack. Of course it's possible that the NSA in cahoots with the aliens has a quantum computer that can MiTM any SSL connection, but even if they do, it's probably sufficiently expensive that they won't do it for every connection, but just for high-value connections. And if not, we're pretty fucked, because a big chunk of the world economy at this point depends on the notion that it is not trivially easy to MiTM SSL connections.
SRP has a number of problems, the most notable being that there's no way to securely *distribute* (or create) the password without falling back to some other TLS suite, or doing it out of band. This really limits the usefulness of SRP in a browser.
Additionally, I'm not sure how browser support for SRP is supposed to make phishing stop working. If the user still needs to enter their password somewhere, then the phishing attack just has to look like wherever they usually enter their password. Yes, an attacker intercepting the network traffic of a legitimate handshake won't be able to extract any useful info about the password (or be able to replay it blindly), but a phishing site that gets users to enter their password and then sends that password back to the (attacker's) server via whatever mechanism it cares to will still work just fine.
On the other hand, there are definitely places that I'd like to see SRP deployed. A key one, which I consider a lot more important than in browsers, would be as a replacement for NTLM hashes (which are antique and terrible) in SMB (Windows networking, Samba, etc.) traffic. It also makes sense for things like remote desktop or ssh (where, at least for password auth, you assume that both sides already know the password so the distribution problem is taken care of). Once you have it in those places, putting it in the browser seems reasonable enough - after all, enterprises do use IE's built-in support for NTLM auth to web servers, which sucks about as much as NTLM for SMB - but I'd put the other areas ahead of the browser.
There's no place I could be, since I've found Serenity...
Well, MS isn't always the fastest on rolling out security features. Somebody else may need to lead the way. If the Mozilla foundation releases HSTS for Firefox 1.0, it might be possible to persuade MS to do the same for their similarly-aged browser...
There's no place I could be, since I've found Serenity...
While man-in-the-middle SSL connections sound like something everyone should be against, those in the corporate environment rely on using an in-line scanner to check for malicious/virus files going in/out the corporate environment. Those entities need to be able to block/report on where those file originated and their final destination. To do that, they rely on the scanning device being the SSL endpoint in order to decrypt and inspect the content. I would hope that this ability will be configurable via AD policy to allow the corporate MitM certificate to be considered trusted; however, there are an increasing number of sites that have javascript which verifies the SSL connection and checks that there is no MitM SSL occuring. While it sounds safe, it actually HELPS virus/malware authors if browsers block MitM connections to ssl sites.
An SSL cert is like $5 from Comodo, so if all browsers checked for MitM connections and prevented access, then corporations can't protect their networks from content on an SSL connection and would have to trust all content from the interwebs.
There are security ramifications to increased security.
SRP has a number of problems, the most
The biggest issues I am aware of is the mostly worthless notion of protecting stored passwords by irreversibly hashing passwords changes.
While stolen SRP verifiers (equivalent of a password hash) can't be used to login to a legitimate system they can like password hashes be used to conduct brute force attacks and they can also be used to trick individuals into thinking they are connecting to a legitimate service. This is equivalent to theft of private key or subversion of CA infrastructure.
The other problem is when PKI is not used with SRP the authenticating identity is transmitted in the clear which may give away information (e.g. a username or alias) to an eavesdropper users may not want disclosed in the clear.
notable being that there's no way to securely *distribute* (or create) the password without falling back to some other TLS suite, or doing it out of band. This really limits the usefulness of SRP in a browser.
Saying that bootstrapping trust is SRPs problem is like saying distributing trusted certificates is PKIs problem.
At some point you need to do work to create trust relationships.. This is fundamentally unavoidable reality the same way people in the real world come to trust or not other individuals based on their experiences.
I do NOT believe SRP is a replacement for PKI. They each have their roles and I believe they can and should be used concurrently. PKI is obviously much better suited for initial service discovery on the Internet. Yet the reality is most sites worth protecting with TLS require a login of some kind. Everyone has a login for their email accounts, their banks and their facebooks... What I find unacceptably dangerous is the world continuing to ignore individual trust relationships to secure sessions... because the alternative is asking hundreds of redundant global trust anchors to be responsible for the security of the worlds systems...a laughably insane delusion.
Additionally, I'm not sure how browser support for SRP is supposed to make phishing stop working. If the user still needs to enter their password somewhere, then the phishing attack just has to look like wherever they usually enter their password.
It becomes tractable to educate users to enter their passwords only into a specific browser menu rather than random attacker forms which appear to be indistinguishable from legitimate counterparts which are constantly subject to change, redesign and often contain baseless security assertions (such as fake padlock imagery and baselessly reassuring text)
On the other hand, there are definitely places that I'd like to see SRP deployed. A key one, which I consider a lot more important than in browsers, would be as a replacement for NTLM hashes
NTLMV2 and Kerberos Authentication both need to be replaced with a modern secure authentication system however a lot more people login to websites using pre-established usernames and passwords than they do a network file share. Many of them have no training and believe whatever they see on their screens because even legitimate sites spew lies to cover for fundamentally indefensible reality where insecure authentication is tolerated.
Comment removed based on user account deletion