HTTP Strict Transport Security Becomes Internet Standard
angry tapir writes "A Web security policy mechanism that promises to make HTTPS-enabled websites more resilient to various types of attacks has been approved and released as an Internet standard — but despite support from some high-profile websites, adoption elsewhere is still low. HTTP Strict Transport Security (HSTS) allows websites to declare themselves accessible only over HTTPS (HTTP Secure) and was designed to prevent hackers from forcing user connections over HTTP or abusing mistakes in HTTPS implementations to compromise content integrity."
Isn't the point of mixed web sites to lessen server load from https? I was always under the impression a mixed environment only using https when necessary was a better idea. Obvoiusly not mixing SSL and non on any single page like the article mentions, but wouldn't just be as effective to advocate for better SSL implementations?
Now, just gotta get SSL certificate system... secure and working.
Whenever *anything* becomes popular -- whatever it is -- it seems to be ruined. It's such a sad fact.
In this case I think that the only practical way to break it would be to break TLS. This is something that many people have tried and with the current version failed (though you should avoid TLS 1.0.
Why not 301? The 302 status is for when you may change your head later, so the client better keep using the same address again and again. With 301 it should only use the new addred from now on.
Rethinking email
Does breaking the PKI consist of break TLS?
Also, with all the recent attacks against the PKI, I'm wondering how the you and the GP are concerned about people suddenly get interest in breaking HTTPS.
Rethinking email
Sure. Not that difficult. Then all the hacker has to do is spoof your site on HTTP and hope people don't notice the address bar isn't green. A number of people will fall for that one.
With HSTS, your brokerage will keep doing the redirect for non-HSTS browsers and for people who are visiting the site the first time. But once they've connected, the browser will note that it's a HSTS site. So next time it'll do the redirect in the browser, where a hacker can't interfere with it, and just do the secure HTTPS connection to the site.
HSTS also makes it impossible for people to click through security warnings, if a hacker is spoofing the HTTPS site with a forged (self-signed) certificate.
What's the difference between using this protocol and, uh, just disabling HTTP on your webserver? Or, from a user standpoint, just making sure you're using HTTPS via the URL?
You are not alone. This is not normal. None of this is normal.
Starting from many Google services. I need to deactivate forced HTTPS in iGoogle because RSS feeds don't work.
Mother used to said If you want you find a way But mother never danced through fire shower
I can get the security side of things, but how do you do that easily and with zero budget? What about a personal website? I can't afford an SSL certificate for that.
Is there any "SSL/HTTPS For Dummies With No Cash" manual somewhere, keeping in mind that most people with websites are code monkeys, not network administrators.
Get free satoshi (Bitcoin) and Dogecoins
This simple logic that when any SECURE page is requested then EVERYTHING must be accessed in secure mode (valid certificate required of every part if the main requested page has a valid certificate) should have been in there right from the beginning. So many of our security problems exists because people just DON'T THINK right at the beginning AND it takes so damn fscking long for the process to fix their stupidity.
now we need to go OSS in diesel cars
And you can get free certs, as long as you don't need extra validation.
It's not the SSL certificate that's the cost bottleneck for the smallest sites; it's the dedicated IPv4 address. A lot of the cheapest use name-based virtual hosting, which requires the Server Name Indication (SNI) extension to SSL. Without SNI, the client can't see any certificate but the first on port 443 of a given address, which means the user will see a serious certificate error most of the time. Popular web browsers that lack SNI support include Internet Explorer for Windows XP, for which Microsoft is providing extended support until April 2014, and Android Browser on Android 2.x, which is on millions of Android phones and many inexpensive Android tablets.
For example, my bank offers online banking. Part of the login for said online banking is hosted on a .NU domain, a completely different country, which I don't even know the exact location of.
The IUSN Foundation of Niue, a tiny island country in the South Pacific, operates .NU as if it were a generic top-level domain like .COM. It has been popular in northern Europe, as "nu" means "now" in Swedish, Danish, and Dutch. (It also means "naked" in French.) McAfee reports that there was a time in 2007 when .nu was a hotbed of browser exploits, but it had been cleaned up by 2008. (source)
SSL is "broken" not by any flaw in the protocol itself but by the flawed trust model used.
Go through mozilla's list of trusted root certificates and realise that every organisation on that list has the power to MITM you without generating a certificate warning (and the power to delegate that power to "intermediate certs" owned by third parties) . Then ask youself whether you really trust every organisation on that list not to MITM you and not to delegate signing powers to an organisation you do not trust.
You can probablly trust SSL to keep most low level criminals out but if something really needs to be kept secret you should be managing keys yourself, ideally through face to face interactions.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Yes, SSL does increase latency, and no, it's not enough to notice in a well written page. But if you go making a ton of different connections, it will be quite noticeable.
So what's the proper way to incorporate advertisements (which pay the writing and hosting bills) and recommendation widgets (which attract readers) "in a well written page"? Those tend to make "a ton of different connections".
Since when do standard HTTP cache control headers, such as Expires at the end of next year, work less efficiently when the HTTP is encapsulated in TLS?
Tell me , if all this is so obvious, how come you didn't design it?
Besides which , when https was designed it was a pretty hefty burden on the server CPUs of the day so it was logical that only the parts that needed security would actually use https. Unfortunately hindsight always does have 20/20 vision and people who pretend its their own insight are usually full of it.
Yes, I agree.
It was a honest question. I wanted to kow if I was overlooking something,
Rethinking email
Most of the time, the proper way to incorporate those things is by assynchronous requests after the page loads.
The implementation on (for example) Cracked.com of asynchronous requests to Facebook and other social networks has caused article pages to reflow several times, and when these reflows move the navigation buttons as they tend to do, I end up clicking links other than the one I intended to click.
Since the cache servers in between the client and the server
Who is operating these cache servers you're talking about?
Oh, you thought only browser caches mattered.
That's exactly what I thought, given the whole goal of SSL.
Accidental clicks on advertisements and "click fraud" look the same to a pay-per-click ad network.
The trust model would have worked a lot better if TLS had allowed multiple certificates of the same key. Major sites would make sure to use several different companies, and browser users could easily dump lousy TLS providers from the trusted roots without losing access to anything important. That would result in actual competition between TLS providers.
Finally! A year of moderation! Ready for 2019?
HTTPS is great, if you can afford to pay the fees. I see tons of potential for redirect 301 to HTTPS, becasue it will screw the existing links on the Internet and the unaware businesses would love to pay for maintenance of their broken websites.
~ Best man at your service.
It's a proposed standard.
If the end user is operating them, such as a business that provides caching for web sites viewed by users of its office network, the business can run an HTTPS caching proxy that uses a self-signed certificate, and everyone behind the firewall can install the business's root certificate.
Every company I do border gateway IT for has a border cache that filters all Internet access for the client.
That's what I was talking about. I don't see why you couldn't just run your own internal CA on a home or office network and use that as part of a man in the middle that caches HTTPS communications.
PS3+PC+Laptop+Tablet+SmartPhones+3DS
Perhaps the problem with running an internal CA happens with devices onto which only the manufacturer, not the device's owner, can install SSL root certificates. Is this the case with the Sony, Nintendo, and perhaps Apple devices that you mentioned?