Moving Towards a More Secure Web
blog.chromium.org
blog.chromium.org
https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-...
But using HTTPS doesn't make a website magically secure, that is not enough. Thus there might be a false sense of security via this option.
> My mom opens browser
> Goes to http://www.example.com
> Sees "insecure" flag, ok moves on.
> Than goes to https://shady.example.com
> Oh nice padlock icon you got there
> It's secure, I can give my credit card info.
Maybe I'm exaggerating. Anyway, it's a good start. HTTPS everywhere, let's encrypt!
Then there is no more false sense of security to the average person, just knowledge of which is insecure.
It's more that HTTP makes it impossible for the site to be secure but HTTPS raises the bar significantly. Google seem to be pushing for HTTPS to be the minimum standard of security.
> Goes to http://example1.com
> Than goes to https://example2.com
How about this one?
https://news.ycombinator.com/item?id=12457809
> Why does Google profit from HTTPS over HTTP? Because it removes the ability for ISPs to act as a competitor to Google by injecting ads and profiling customer browsing. You may not like that ISPs have done that (I don't) but it's competition for Google, and removing it is therefore good for Google's profits.
Trusting certificates issued by CAs, companies that have no 'skin in the game' (WoSign), or are too big to fail (Symantec, Comodo, ...) won't work for what we actually want to do (securing the transport layer of critical infrastructure, all the way to sharing economy, and even online-banking).
More HSTS/HPKP?
Certificate pinning (HPKP) is a great example of "security as an after-thought". Not that it's bad (HPKP is great if you know what you're doing) but it's unpractical and can seriously brick your site. There are also several other attack vectors against HPKP: https://news.ycombinator.com/item?id=12434585
The solution isn't to bolt on more X509 on top of a broken foundation. It is on the other hand so typical of how we fix issues in engineering.
HTTPS breaks proxies and breaks caching. Which is a crucial part of the architecture of the web.
And that's a huge issue especially for developing countries. Bandwidth is costly and the way telcos exchange does not help.
Most of our activity on the web is public as in a public space. That's fine and maybe even actually good. There is no need to scare people from HTTP, we should educate people on how to use public spaces on the internet
SRI doesn't protect or verify the downloads of html pages generally.
> HTTPS breaks proxies and breaks caching.
I wonder if RFC 2660 S-HTTP[1] would have helped here.
> Most of our activity on the web is public as in a public space. That's fine and maybe even actually good.
I think what we've discovered is that this isn't actually true: many things do need to be secret, and in order for things to be secret those things need to hide in a cloud of things which don't really matter.
You always had to trust the proxy; this just makes the trust explicit.
I don't remember, but it doesn't appear that that was the case:
> We use https to protect your password every time you log into Gmail, but we don't use https once you're in your mail unless you ask for it
https://gmail.googleblog.com/2008/07/making-security-easier....
This makes me happy to read.
This is already an issue for me today. Fortunately I can still tell it to go to example.com without issue, and log in from there. But if they stick up warnings on http I may be in a position to have to have a second browser just for wifi logins.
http://verylongrandomstring.io
Should do the trick.
So yeah.. enforcing https may be the same as trying to patch a hole when the bag is wide open..
It will simply become even less feasible for sombody to host a site without the blessing of the big cert guys...
Federalization of the internet is where we are going, but I susppose that's just the faith of all media channels..
Thank you!
Why can't you issue certificates for your subdomains? Running OpenSSL is as easy for you as it is for a CA.
IDK why Let's Enrypt has this policy.
In case of browsers, it's luckily still only a theoretical concern today, thanks to the "custom root cert" loophole which practically works like a permission system for monitoring tools. However, I think the conceptual change is important: With HTTP, the abillity to monitor your own connections is a simple technical consequence. With HTTPS, its a feature that browsers explicitely have to implement and that's potentially subject to all kinds of tradeoffs and political descisions.
I fear that once HTTPS is actually the norm, there will be a number of strong forces to have the loophope removed and make HTTPS connections effectively opaque to everyone but the website operators.
Of course HTTP is no long-term solution as the security risks are real. But you could get rid of most of the risks by focusing on ensuring message integrity while keeping connections transparent. Instead we get an all-or-nothing solution where a connection has to be integrity checked AND encrypted to be considered "secure" by browsers.
Sometimes the answer is "just go ahead but lose the green bar".
Sometimes the answer is "pop a click-through warning". (We click through these warnings, but they bounce significant numbers of end users).
Sometimes the answer is "scream bloody murder to the browser vendor".
What does it even mean to trust a signature? Do we trust things that come from hierarchical PKIs? Would we rather rely mostly on key continuity, like SSH does? Do we want to build something like Moxie Marlinspike's Convergence, long term, so we can choose which authorities we trust?
All of these concerns that I listed could be handled in an encryption capability that resided directly in the transport layer. But we'd inevitably come up with concerns that were difficult to handle there --- for instance, if it's part of TCP/IP, the code is mostly kernel resident, and maybe it's super hard (even harder than it is now) to get Curve25519 deployed.
This isn't so much insight on my part as it is the stated conclusion, about security in particular, of Saltzer, Reed, and Clark's "End To End Argument In Systems Design", which is one of the foundational documents of the Internet:
http://web.mit.edu/Saltzer/www/publications/endtoend/endtoen...
Push things as far towards the application layer as they'll go, and keep the lower-layer protocols dumb, so they don't get in the way.
Here's a more reasonable approach that probably addresses the concerns you have about there being multiple app-layer crypto protocols:
[1] https://tools.ietf.org/html/draft-hamilton-early-deployment-...
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1158011
[3] https://daniel.haxx.se/blog/2016/07/20/curl-wants-to-quic/
Nowadays middleboxes violating basic TCP/IP guarantees[1] are so accepted and entrenched that all new protocol work necessarily uses UDP encapsulation. (See eg WebRTC data channels, that's SCTP over DTLS over UDP...)
[1] Many are calling NAT boxes "routers" even though the most central specified requirement of an IP router is to pass IP datagrams through with addressing information unaltered!
How about IPv6? We'd most likely have 40-bit export ciphers, if anything, but crypto was still considered a "munition" by the US govt when IPv6 work began in the 1990s. Perhaps IPv6 would have taken longer due to that fight, and later adopted 40-bit export if we were "lucky." IPv6 carries a measurable percentage of Internet traffic now, but when it was developed, in the 1990s, public crypto sucked. And so that's what would be baked into IPv6 now, for all time.
I totally get the appeal of having all traffic automatically encrypted, it's just that A) IETF would screw it up somehow and B) it would take too long to deploy through "official" channels. It would turn into an unwanted Christmas present, 20 years too late.
The alternative offers much stronger crypto and a much faster deployment timetable: let the public build encrypted protocols based on UDP. If they work, maybe people will use them. There's actually been some success here, like with QUIC, Noise, etc.
I think we need to get beyond the idea of waiting for standards bodies to give us state-of-the-art. They have a terrible track record. We can do better ourselves, and already are.
You could imagine a more complex architecture involving DNSSEC and results from getaddrinfo(), but that seems to break the end-to-end principle (it is the browser that cares whether I am actually talking to news.ycombinator.com or not) and also reinvent the wheel. We have an HTTPS ecosystem that works pretty well. We do not have a secure DNS system that works pretty well, let alone a secure TCP/IP one.
HTTPS is all or nothing, an in-between "only on the pages that need it" isn't going to cut it.
This is just the chrome team's first step (actually more like 5th or 6th step in this plan) toward getting there.
Labeling HTTP as insecure is just plain wrong. I would beg to differ, sometimes HTPS is more insecure than HTTP: think of Hearthbleed bug that made servers with HTTPS vulnerable or certs that shouldn't be trusted, or the day when all LetsCrypt users were vulnerable, etc. Also you will loose a lot of ad-money. Of course Google with their search monopoly wants HTTPS because they profit from it. It's sad that Mozilla is influenced by some lobbyist. Well hopefully the popular forks on Linux distros remove that stupid warning label.
Why does Google profit from HTTPS over HTTP?
Amazon.com (HTTP) redirects to (HTTPS), via a 301 - that's Permanent Redirection.
This also isn't Mozilla, but Chrome.
And honestly i don't even know where to begin, but you should look into HSTS, and the vulnerabilities that exist transitioning between the two modes[1],
as well as looking at the issues (data bleed, etc) that happen with a http+https web and mixed content.
Finally the bigger issue to ad rev is likely to be cross origin content rather than https.
and, er, semantically there's a gulf of difference between "Not Secure" and "Insecure".
Also, arguably, the shift to a https first web is what's helping us shine light into bad CAs and deeper audits that are finding the esoteric bugs -- so it's only a good thing, in the long term.
[1]: http://michael-coates.blogspot.com/2009/02/compromising-http...
Because it removes the ability for ISPs to act as a competitor to Google by injecting ads and profiling customer browsing.
You may not like that ISPs have done that (I don't) but it's competition for Google, and removing it is therefore good for Google's profits.
For instance, if Wikipedia were http only your ISP would see that you visited http://en.wikipedia.com/really-bad-disease whereas a https url would only reveal that you visited Wikipedia.
A major problem in North America is one of ISPs and Hotels injecting ads into HTTP requests.
I would say most internet users still have a neutral ISP if you look at it at grander world wide view. And as long as HTTP works so fine for all Amazon e-commerce websites "beside their US centric Amazin.com" (as I wrote, but some didn't get), I am the opinion that HTTP is a viable option and shouldn't be treated as legacy by Google at all. The whole HTTP/2 movement seems fishy to me, if you know how it works and who benefits the most, then you know also why they lobby for it.but as they now try to deprecate HTTP/1 that a very evil move, and everyone who supports that because he gets paid for lobbying should be very ashamed (and sure some users are still ill informed and go with the masses, nothing new, but they were previously not part of the HN community, but on other sites like Reddit or whatever).
I've checked amazon.de, amazon.co.uk, amazon.fr, amazon.ca and amazon.de, and they're all served via HTTPS (including a HTTP->HTTPS redirect).
HTTP connections are vulnerable to MITM attacks 100% of the time. HTTPS-related vulnerabilities are rare and have rarely been worse than degrading the connection to HTTP security.
Why would Google uniquely profit from HTTPS?
That is the idea of the "insecure" text, they will display it when the browser detects a form with a password field, a form requesting credit card information, and stuff like that. I am not completely sure, but I believe they will continue showing the information icon only for the rest of the pages if the site is not on HTTPS.
1) Two steps forward (ignoring all user feedback, focused on internal aganda)
2) Public outcry, pending backslash
3) One step back (PR announcement like "we care..., we want the best for the user...), repeat with step 1
Everyone who knows about how it works, will hate that tactics. Sadly, many with less insight fall for such evil tactics.
If your website uses sessions at all, you need to use HTTPS just to protect from session hijacking. On every page. Better yet, mark that cookie as secure-only.
EDIT: I take the above comment back. The chrome.exe processes match with the process running in the Chrome's Task Manager. I stand corrected.
However, I think there's something new about the latest upgrade. The interface looks heavy and different. This is the same upgrade which has removed the green colored SSL identifier in the URL bar.
Chrome uses a multi-process architecture. So you have a process for the "browser", a process for each extension installed, a process for each tab, a process for the GPU renderer, processes for if it's pre loading a page in the background, etc...
Many of them share memory.
If you want a bunch of details about all of this, press "Shift + escape" while in chrome and it will open the chrome task manager which shows a bunch of this and more.