9 ms·

Moving Towards a More Secure Web

125 points by kungfudoi 10y ago

mkagenius 10y ago
Nice. Mobile apps world should also move quickly. I had written about it earlier here: https://medium.com/@mkagenius/where-is-my-https-for-mobile-apps-aa8bcece5954#.fksay64ms https://medium.com/@mkagenius/where-is-my-https-for-mobile-a...
- imajes 10y ago
  You mean like ATS on iOS 9+ ?
  - mkagenius 10y ago
    Yes! Android should also do something similar.
diegorbaquero 10y ago
There's no excuse now that we have LetsEncrypt. Thank you!
- Mahn 10y ago
  LetsEncrypt still has some limitations though, namely no wildcard certificates, which means you need to issue and update certificates for every subdomain individually. Certbot helps, but it's still a hassle at a certain scale. We'd gladly migrate to LetsEncrypt, but for us (+40 subdomains) it's still far simpler to manage using a paid wildcard certificate from CAcert.
  - mordocai 10y ago
    To be fair, you can do a large amount of subdomains (I don't remember the limit) with one certificate request on letsencrypt. Of course, if you're going to be changing them often then it becomes a real PITA.
- zzzcpan 10y ago
  Not an option for websites with lots of subdomains. And probably will never be.
  - zeveb 10y ago
    The Right Thing™, of course, would be to accept that if you own a domain you own all subdomains, and delegate the authority to certify subdomains to you, the owner. Why can't you issue certificates for your subdomains? Running OpenSSL is as easy for you as it is for a CA.
    - paulddraper 10y ago
      Sure, but someone has to let you be a CA. IDK why Let's Enrypt has this policy.
      - zeveb 10y ago
        One should be allowed to be a CA for everything under one's domain, and nothing else. The idea that every CA must necessarily be trusted for every name in the world is … insane.
azureel 10y ago
Every HTTP site is insecure, that's OK and we all agree on that. 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 http://www.example.com > Sees "insecure" flag, ok moves on. > Than goes to https://shady.example.com 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!
- cmdrfred 10y ago
  Don't the people who own example.com also own shady.example.com? example.net would be a more likely case.
  - seanwilson 10y ago
    Maybe one subdomain is served over HTTP and the other subdomain is served over HTTPS. Lots of sites still do this where the area you login to is under HTTPS but the rest is under HTTP.
    - cmdrfred 10y ago
      Comment specifies the protocol used "Than goes to https://shady.example.com" https://shady.example.com"
      - azureel 10y ago
        Yeap, you're right. I can correct the example; > Goes to http://example1.com http://example1.com > Than goes to https://example2.com https://example2.com How about this one?
- seanwilson 10y ago
  > 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. 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.
toomim 10y ago
A page can be http, but what matters is if the fork submits to a https url. Does chrome care about how the page was loaded, or what the form submits as?
- cmg 10y ago
  If the page is plain HTTP, it's possible for there to be malicious edits - adding a keystroke logger, changing the form's action to point to somewhere else entirely that saves credentials and redirects back to the original service the user meant to log in to, etc. So it matters very much that the page with the credit card or password field is HTTPS.
  - Klathmon 10y ago
    And the even more sinister "include a malware payload into an asset which was requested". Drive-by infection of exe's, injecting video streams with payloads that can take advantage of the StageFright vulnerability, not to mention things like session hijacking that can happen if any part of a page is loaded over http. 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.
    - xg15 10y ago
      Until of course you get similar vulnerabilities (Heardbleed etc) in the TLS implementation itself...
  - geofft 10y ago
    Yeah. You also want the page to redirect back to an HTTPS site when you're logged in, otherwise anyone who can intercept your communication can wait until you've logged in securely over HTTPS, and steal the auth token / cookie / whatever that's sent back through HTTP.
cpeterso 10y ago
Firefox 46+ adds a red "no lock" icon for http:// http:// pages with a password field. Chrome's explicitly saying "Not secure" is a big step beyond. I hope it sticks! https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/ https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-...
- johnnydoebk 10y ago
  I think the problem with the Firefox's "red" "no lock" icon is than it is mostly gray. Many people do not even notice it. I think if it were actually red the effect would be much stronger.
Cortez 10y ago
But saying something is insecure doesn't make it secure.
- StavrosK 10y ago
  Yes it does, it forces people to avoid it, indirectly forcing the creator to make it secure.
  - Cortez 10y ago
    Avoiding it doesn't push to make it secure, communicating with the creator directly will.
    - StavrosK 10y ago
      It's unreasonable to expect Google to email every website owner in the world to tell them to switch to TLS.
    - nsgi 10y ago
      Lots of people avoiding it will give the creator a much bigger incentive, though.
- imajes 10y ago
  No. However, Google have a plan for this. Apparently right now HTTPS is considered a 'strong signal' in google rankings, which normally gets the message to most site owners/product people.
amelius 10y ago
Shouldn't encryption be part of TCP/IP, rather than have every application including web browsers reinvent the wheel?
- niftich 10y ago
  If Google has its way, encryption is a part of their TCP-replacement, QUIC [1]. Google products already use QUIC in the wild; Firefox is adding it soon [2]; curl put out a request for a QUIC library [3]. [1] https://tools.ietf.org/html/draft-hamilton-early-deployment-quic-00 https://tools.ietf.org/html/draft-hamilton-early-deployment-... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1158011 https://bugzilla.mozilla.org/show_bug.cgi?id=1158011 [3] https://daniel.haxx.se/blog/2016/07/20/curl-wants-to-quic/ https://daniel.haxx.se/blog/2016/07/20/curl-wants-to-quic/
  - tptacek 10y ago
    QUIC is sort of a counterexample, but it's also an example of a vertically-integrated application protocol that takes responsibility for transport as well.
- geofft 10y ago
  No, it should not. TCP/IP doesn't have a concept of names. I want to know that I am sending my HN password / login cookies to news.ycombinator.com. I don't have any idea whether I should send my HN password to 104.20.43.44:80 or not. 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.
- tptacek 10y ago
  No, it should not. Security involves policy decisions; for instance, "how should I respond when confronted with an expired certificate with a valid signature", or, "how should I handle a certificate when I can't verify whether it's been revoked", or "how should I handle a valid certificate for a pinned domain". 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/endtoend.txt 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: http://noiseprotocol.org/ http://noiseprotocol.org/
StavrosK 10y ago
This is a great move towards more security. I can't believe I remember a time when Facebook's login form was over plain HTTP.
- blowski 10y ago
  As was Gmail, I seem to remember.
  - magicalist 10y ago
    > As was Gmail, I seem to remember 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.html https://gmail.googleblog.com/2008/07/making-security-easier....
    - blowski 10y ago
      Oh yes, you're right.
webwanderings 10y ago
This latest upgrade of Chrome uses a lot more memory on my Win7. I run 5 tabs and I see 10 chrome.exe running processes. WTF and why? 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.
- Klathmon 10y ago
  This has been like this since before chrome version 1.0 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.
bobajeff 10y ago
Doesn't moving everything to https make the Web even more centralized? In order to use it looks like site's have to submit to a certificate authority now.
- ajross 10y ago
  For some definition of "submit", I guess. Non-EV certificates are based on domain ownership. If you can prove you own the domain (e.g. Let's Encrypt just checks that you can host a static file on a HTTP page on the certified hostname) then you can get a cert for it. Obviously you still have to "submit" to the domain registrars also...
  - paulddraper 10y ago
    It was always centralized (though "federated" would be more accurate), with allocated IP blocks and domain registrars.
- zer0gravity 10y ago
  It is. There will also be a high incentive for hackers to attack at take control of some certificate autorities. And it will be worse than accepting self signed certificates as trusted solutions...
  - nathanaldensr 10y ago
    Wouldn't hackers already have that incentive? It seems like virtually all sites worth targeting would already be secured by TLS certificates, so the remaining sites wouldn't provide much value to hackers.
    - zer0gravity 10y ago
      They would. And apparently they're doing it with some success, judging by all the passwords leaked lately. We can assume there were other "successes" that were not made public yet.. 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..
bugmen0t 10y ago
Btw, this web page has a nice overview of what security indicators look like on different web browsers: http://lock-museum.herokuapp.com/ http://lock-museum.herokuapp.com/
gooseserbus 10y ago
The irony of posting this link as http when https is available
frik 10y ago
HTTP is fine for most websites. HTTPS makes sense for certain parts of websites like e-commerce. Even Amazon website (beside .com) is HTTP with only the login page and checkout page on a HTTPS sub-domain. It's fine since 1995, and no one complains or has problems with that. 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.
- imajes 10y ago
  Why are you going to lose Advertiser money? That's bogus. 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-to-https-redirects.html http://michael-coates.blogspot.com/2009/02/compromising-http...
  - throwaway6845 10y ago
    > 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.
- guessmyname 10y ago
rocky1138 10y ago
"more than half of Chrome desktop page loads now served over HTTPS" This makes me happy to read.
- bzbarsky 10y ago
  Would rephrasing as "more than half of Chrome desktop page load are Google or Facebook properties" still make you happy? I suspect that's a very large part of what's going on there.
slim 10y ago
There's one component of the web that everybody seem to forget : the proxy. 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
- zeveb 10y ago
  > There's one component of the web that everybody seem to forget : the proxy. > 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. [1] https://tools.ietf.org/html/rfc2660 https://tools.ietf.org/html/rfc2660
  - slim 10y ago
    Secret from whom? Most of the information we're talking about is shared among CDNs and Ad networks. It just gives a false sense of privacy to consider this kind of information private
  - slim 10y ago
    S-HTTP looks awesome. I did no know about it. Thanks
- AgentME 10y ago
  HTTPS not only protects against eavesdroppers: it also protects against from people manipulating the connection and replacing content (like swapping exe downloads for infected executables). If untrusted caching-proxies are important, then there should be a new caching-proxy-compatible protocol which carries signed data without encrypting it, and browsers should communicate when it's in use.
zubat 10y ago
Ok, but how do I get on the coffeeshop wifi if Chrome is my only browser and it throws up a warning page with no "ignore and continue" before I can log in? 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.
- 3pt14159 10y ago
  You can request a page that doesn't exist. http://verylongrandomstring.io http://verylongrandomstring.io Should do the trick.
  - slavik81 10y ago
    Be sure to generate a different one for each connection attempt. https://github.com/sindresorhus/is-up/issues/5 https://github.com/sindresorhus/is-up/issues/5
xg15 10y ago
Interesting point which unfortunately got buried in this thread due to being a reply to another comment: https://news.ycombinator.com/item?id=12457809 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.
- DyslexicAtheist 10y ago
  the industry has previously responded by installing their own root certificates into the trust-store of the OS. Mobile operator supplied versions of android are a good example, ... on notebooks we got Lenovo, ... http://www.wilderssecurity.com/threads/superfish-is-not-the-only-one.373647/ http://www.wilderssecurity.com/threads/superfish-is-not-the-... 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 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.
hsdnj_th3 10y ago
the certificate system is fundamentally broken, it's better than nothing but pushing so hard for a broken system is frustrating.
xg15 10y ago
What I don't like about the whole HTTPS everywhere initiative is that it makes it even harder to monitor what data is traveling to and from your own PC. 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.
- extra88 10y ago
  I'm not concerned about that happening. I think EMEs being used for not just video but entire page content is a more likely risk.

125 points by kungfudoi 10y ago

Nice. Mobile apps world should also move quickly. I had written about it earlier here: https://medium.com/@mkagenius/where-is-my-https-for-mobile-apps-aa8bcece5954#.fksay64ms https://medium.com/@mkagenius/where-is-my-https-for-mobile-a...

imajes 10y ago
You mean like ATS on iOS 9+ ?
- mkagenius 10y ago
  Yes! Android should also do something similar.

diegorbaquero 10y ago

There's no excuse now that we have LetsEncrypt. Thank you!

Mahn 10y ago
LetsEncrypt still has some limitations though, namely no wildcard certificates, which means you need to issue and update certificates for every subdomain individually. Certbot helps, but it's still a hassle at a certain scale. We'd gladly migrate to LetsEncrypt, but for us (+40 subdomains) it's still far simpler to manage using a paid wildcard certificate from CAcert.
- mordocai 10y ago
  To be fair, you can do a large amount of subdomains (I don't remember the limit) with one certificate request on letsencrypt. Of course, if you're going to be changing them often then it becomes a real PITA.
zzzcpan 10y ago
Not an option for websites with lots of subdomains. And probably will never be.
- zeveb 10y ago
  The Right Thing™, of course, would be to accept that if you own a domain you own all subdomains, and delegate the authority to certify subdomains to you, the owner. Why can't you issue certificates for your subdomains? Running OpenSSL is as easy for you as it is for a CA.
  - paulddraper 10y ago
    Sure, but someone has to let you be a CA. IDK why Let's Enrypt has this policy.
    - zeveb 10y ago
      One should be allowed to be a CA for everything under one's domain, and nothing else. The idea that every CA must necessarily be trusted for every name in the world is … insane.

azureel 10y ago

Every HTTP site is insecure, that's OK and we all agree on that. 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 http://www.example.com > Sees "insecure" flag, ok moves on. > Than goes to https://shady.example.com 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!

cmdrfred 10y ago
Don't the people who own example.com also own shady.example.com? example.net would be a more likely case.
- seanwilson 10y ago
  Maybe one subdomain is served over HTTP and the other subdomain is served over HTTPS. Lots of sites still do this where the area you login to is under HTTPS but the rest is under HTTP.
  - cmdrfred 10y ago
    Comment specifies the protocol used "Than goes to https://shady.example.com" https://shady.example.com"
    - azureel 10y ago
      Yeap, you're right. I can correct the example; > Goes to http://example1.com http://example1.com > Than goes to https://example2.com https://example2.com How about this one?
seanwilson 10y ago
> 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. 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.

toomim 10y ago

A page can be http, but what matters is if the fork submits to a https url. Does chrome care about how the page was loaded, or what the form submits as?

cmg 10y ago
If the page is plain HTTP, it's possible for there to be malicious edits - adding a keystroke logger, changing the form's action to point to somewhere else entirely that saves credentials and redirects back to the original service the user meant to log in to, etc. So it matters very much that the page with the credit card or password field is HTTPS.
- Klathmon 10y ago
  And the even more sinister "include a malware payload into an asset which was requested". Drive-by infection of exe's, injecting video streams with payloads that can take advantage of the StageFright vulnerability, not to mention things like session hijacking that can happen if any part of a page is loaded over http. 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.
  - xg15 10y ago
    Until of course you get similar vulnerabilities (Heardbleed etc) in the TLS implementation itself...
- geofft 10y ago
  Yeah. You also want the page to redirect back to an HTTPS site when you're logged in, otherwise anyone who can intercept your communication can wait until you've logged in securely over HTTPS, and steal the auth token / cookie / whatever that's sent back through HTTP.

cpeterso 10y ago

Firefox 46+ adds a red "no lock" icon for http:// http:// pages with a password field. Chrome's explicitly saying "Not secure" is a big step beyond. I hope it sticks! https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/ https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-...

johnnydoebk 10y ago
I think the problem with the Firefox's "red" "no lock" icon is than it is mostly gray. Many people do not even notice it. I think if it were actually red the effect would be much stronger.

Cortez 10y ago

But saying something is insecure doesn't make it secure.

StavrosK 10y ago
Yes it does, it forces people to avoid it, indirectly forcing the creator to make it secure.
- Cortez 10y ago
  Avoiding it doesn't push to make it secure, communicating with the creator directly will.
  - StavrosK 10y ago
    It's unreasonable to expect Google to email every website owner in the world to tell them to switch to TLS.
  - nsgi 10y ago
    Lots of people avoiding it will give the creator a much bigger incentive, though.
imajes 10y ago
No. However, Google have a plan for this. Apparently right now HTTPS is considered a 'strong signal' in google rankings, which normally gets the message to most site owners/product people.

amelius 10y ago

Shouldn't encryption be part of TCP/IP, rather than have every application including web browsers reinvent the wheel?

niftich 10y ago
If Google has its way, encryption is a part of their TCP-replacement, QUIC [1]. Google products already use QUIC in the wild; Firefox is adding it soon [2]; curl put out a request for a QUIC library [3]. [1] https://tools.ietf.org/html/draft-hamilton-early-deployment-quic-00 https://tools.ietf.org/html/draft-hamilton-early-deployment-... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1158011 https://bugzilla.mozilla.org/show_bug.cgi?id=1158011 [3] https://daniel.haxx.se/blog/2016/07/20/curl-wants-to-quic/ https://daniel.haxx.se/blog/2016/07/20/curl-wants-to-quic/
- tptacek 10y ago
  QUIC is sort of a counterexample, but it's also an example of a vertically-integrated application protocol that takes responsibility for transport as well.
geofft 10y ago
No, it should not. TCP/IP doesn't have a concept of names. I want to know that I am sending my HN password / login cookies to news.ycombinator.com. I don't have any idea whether I should send my HN password to 104.20.43.44:80 or not. 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.
tptacek 10y ago
No, it should not. Security involves policy decisions; for instance, "how should I respond when confronted with an expired certificate with a valid signature", or, "how should I handle a certificate when I can't verify whether it's been revoked", or "how should I handle a valid certificate for a pinned domain". 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/endtoend.txt 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: http://noiseprotocol.org/ http://noiseprotocol.org/

StavrosK 10y ago

This is a great move towards more security. I can't believe I remember a time when Facebook's login form was over plain HTTP.

blowski 10y ago
As was Gmail, I seem to remember.
- magicalist 10y ago
  > As was Gmail, I seem to remember 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.html https://gmail.googleblog.com/2008/07/making-security-easier....
  - blowski 10y ago
    Oh yes, you're right.

webwanderings 10y ago

This latest upgrade of Chrome uses a lot more memory on my Win7. I run 5 tabs and I see 10 chrome.exe running processes. WTF and why? 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.

Klathmon 10y ago
This has been like this since before chrome version 1.0 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.

bobajeff 10y ago

Doesn't moving everything to https make the Web even more centralized? In order to use it looks like site's have to submit to a certificate authority now.

ajross 10y ago
For some definition of "submit", I guess. Non-EV certificates are based on domain ownership. If you can prove you own the domain (e.g. Let's Encrypt just checks that you can host a static file on a HTTP page on the certified hostname) then you can get a cert for it. Obviously you still have to "submit" to the domain registrars also...
- paulddraper 10y ago
  It was always centralized (though "federated" would be more accurate), with allocated IP blocks and domain registrars.
zer0gravity 10y ago
It is. There will also be a high incentive for hackers to attack at take control of some certificate autorities. And it will be worse than accepting self signed certificates as trusted solutions...
- nathanaldensr 10y ago
  Wouldn't hackers already have that incentive? It seems like virtually all sites worth targeting would already be secured by TLS certificates, so the remaining sites wouldn't provide much value to hackers.
  - zer0gravity 10y ago
    They would. And apparently they're doing it with some success, judging by all the passwords leaked lately. We can assume there were other "successes" that were not made public yet.. 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..

bugmen0t 10y ago

Btw, this web page has a nice overview of what security indicators look like on different web browsers: http://lock-museum.herokuapp.com/ http://lock-museum.herokuapp.com/

gooseserbus 10y ago

The irony of posting this link as http when https is available

frik 10y ago

HTTP is fine for most websites. HTTPS makes sense for certain parts of websites like e-commerce. Even Amazon website (beside .com) is HTTP with only the login page and checkout page on a HTTPS sub-domain. It's fine since 1995, and no one complains or has problems with that. 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.

imajes 10y ago
Why are you going to lose Advertiser money? That's bogus. 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-to-https-redirects.html http://michael-coates.blogspot.com/2009/02/compromising-http...
- throwaway6845 10y ago
  > 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.
guessmyname 10y ago

rocky1138 10y ago

"more than half of Chrome desktop page loads now served over HTTPS" This makes me happy to read.

bzbarsky 10y ago
Would rephrasing as "more than half of Chrome desktop page load are Google or Facebook properties" still make you happy? I suspect that's a very large part of what's going on there.

slim 10y ago

There's one component of the web that everybody seem to forget : the proxy. 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

zeveb 10y ago
> There's one component of the web that everybody seem to forget : the proxy. > 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. [1] https://tools.ietf.org/html/rfc2660 https://tools.ietf.org/html/rfc2660
- slim 10y ago
  Secret from whom? Most of the information we're talking about is shared among CDNs and Ad networks. It just gives a false sense of privacy to consider this kind of information private
- slim 10y ago
  S-HTTP looks awesome. I did no know about it. Thanks
AgentME 10y ago
HTTPS not only protects against eavesdroppers: it also protects against from people manipulating the connection and replacing content (like swapping exe downloads for infected executables). If untrusted caching-proxies are important, then there should be a new caching-proxy-compatible protocol which carries signed data without encrypting it, and browsers should communicate when it's in use.

zubat 10y ago

Ok, but how do I get on the coffeeshop wifi if Chrome is my only browser and it throws up a warning page with no "ignore and continue" before I can log in? 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.

3pt14159 10y ago
You can request a page that doesn't exist. http://verylongrandomstring.io http://verylongrandomstring.io Should do the trick.
- slavik81 10y ago
  Be sure to generate a different one for each connection attempt. https://github.com/sindresorhus/is-up/issues/5 https://github.com/sindresorhus/is-up/issues/5

xg15 10y ago

Interesting point which unfortunately got buried in this thread due to being a reply to another comment: https://news.ycombinator.com/item?id=12457809 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.

DyslexicAtheist 10y ago
the industry has previously responded by installing their own root certificates into the trust-store of the OS. Mobile operator supplied versions of android are a good example, ... on notebooks we got Lenovo, ... http://www.wilderssecurity.com/threads/superfish-is-not-the-only-one.373647/ http://www.wilderssecurity.com/threads/superfish-is-not-the-... 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 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.

hsdnj_th3 10y ago

the certificate system is fundamentally broken, it's better than nothing but pushing so hard for a broken system is frustrating.

xg15 10y ago

What I don't like about the whole HTTPS everywhere initiative is that it makes it even harder to monitor what data is traveling to and from your own PC. 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.

extra88 10y ago
I'm not concerned about that happening. I think EMEs being used for not just video but entire page content is a more likely risk.