15 ms·

Marking HTTP as Non-Secure

399 points by diafygi 12y ago

diafygi 12y ago
Previous discussion in Firefox: https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/iU86qMOwvWs https://groups.google.com/forum/m/#!topic/mozilla.dev.securi... https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 Chromium: https://groups.google.com/a/chromium.org/forum/m/#!topic/security-dev/DHQLv76QaEM https://groups.google.com/a/chromium.org/forum/m/#!topic/sec... https://groups.google.com/a/chromium.org/forum/m/#!topic/security-dev/rGM2oiKZqZU https://groups.google.com/a/chromium.org/forum/m/#!topic/sec...
andrewstuart2 12y ago
I think the best time to do this would be soon after the Let's Encrpyt free CA [1] starts handing out certificates. There's no more good reason not to have HTTPS, so that's a good time to start applying a little pressure and adding the incentive for website authors. Does google already reward secure sites with higher search rankings? I can't decide if I think that's a good idea or not, but if they want to push for a more secure and free web, that's definitely another avenue. [1] https://www.eff.org/press/releases/new-free-certificate-authority-dramatically-increase-encrypted-internet-traffic https://www.eff.org/press/releases/new-free-certificate-auth...
- TimWolla 12y ago
  > Does google already reward secure sites with higher search rankings? They do: http://googlewebmastercentral.blogspot.de/2014/08/https-as-ranking-signal.html http://googlewebmastercentral.blogspot.de/2014/08/https-as-r...
- alexbecker 12y ago
  > Does google already reward secure sites with higher search rankings? Yes, although only recently and only slightly. http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html http://googlewebmastercentral.blogspot.com/2014/08/https-as-...
- Touche 12y ago
  I still haven't heard a reason why it's important that my blog is on https. Waiting.
  - abdullahkhalids 12y ago
    There is no reason. Your readers will probably not care that the browser tells them your cat pictures are being delivered to them in a non-secure manner. You shouldn't put in the work to switch over either. But in 2 years it will be easier for you to have a https blog than a http blog and you will naturally switch.
    - MichaelGG 12y ago
      What about when a trusted cat blog starts providing instructions harmful to cats? Or a recipes site sends incorrect information regarding allergies?
  - mgraczyk 12y ago
    Some users might want to be sure that the content of your blog as is rendered on their screen is truly the content of your blog. Or perhaps there are users who do not want others to know which specific posts on your blog they have viewed.
    - Touche 12y ago
      Some users might not like my font choice either, but I don't think the browser should judge my site to be inferior because of that.
      - deleted 12y ago
        [deleted]
      - mayneack 12y ago
        If your site has auto-playing sound, would you be opposed to chrome adding the speaker indicator on the tab to alert users that your tab is causing the sound?
- Donzo 12y ago
  There is a very good reason to not secure your site if you are dependent on ad revenue. When I switched to https, my earnings dropped by about half. I tried it for a week, but I couldn't take the losses. When you have a secure site that uses Adsense, Google only serves ads from secure ad servers. This shrinks the pool of competing bidders significantly. For me to switch back, either Google needs to push advertising networks into securing their ad servers, or the nonsecure warning will have to be really big and scary.
  - hashtree 12y ago
    This is a really interesting observation. Can you expand upon what "shrinks the pool of competing bidders significantly" means? For instance, when creating an Ad Words campaign, is there a setting/option that they must opt-in to and if they do not they won't be considered for secure-only advertising?
    - taspeotis 12y ago
      I'm guessing it means that ads that lead to http:// http:// urls get binned.
      - coldtea 12y ago
        No, ads that originate from such urls get binned.
    - Donzo 12y ago
      Here is relevant information about it taken from this page: https://support.google.com/adsense/answer/10528?hl=en https://support.google.com/adsense/answer/10528?hl=en "HTTPS-enabled sites require that all content on the page, including the ads, be SSL-compliant. As such, AdSense will remove all non-SSL compliant ads from competing in the auction on these pages. If you do decide to convert your HTTP site to HTTPS, please be aware that because we remove non-SSL compliant ads from the auction, thereby reducing auction pressure, ads on your HTTPS pages might earn less than those on your HTTP pages."
    - 12y ago
- jedberg 12y ago
  > There's no more good reason not to have HTTPS Cost. Today I host my website for 6 cents a month as a static page on Amazon S3. To go https, I'd have to first acquire a certificate (lucky that can be free and with Let's Encrypt will be). Then I have to find someone to host that certificate. I can pay someone hundreds to thousands of dollars in setup and monthly fees. Or, the cheapest option I've found is to get a $6/mo VPS as a frontend, put nginx on it, and put my cert there. The problem is that costs 100 times as much as what I pay now, and I have to maintain a server and it's not served from multiple redundant servers like my site is now. Or I can use Amazon's free SNI support, making it so that older browsers can't see my site and I have no way of blocking people from using http or redirecting them. There is currently no good, cheap option to do SSL only that is viewable by everyone. That's why I haven't switched yet.
  - coldtea 12y ago
    >The problem is that costs 100 times as much as what I pay now The "100 times as much" is not that impressive, if it merely goes from 6 cents to 6 dollars.
    - egwor 12y ago
      Which in big chunks of the western world is not that much, but it will increase the barrier for entry for many in poorer nations. For commercial sites, then maybe I see a benefit. For everything else... why bother? The info isn't secret, doesn't need to be and since there's so much data going around already is anyone malicious bothering to look?
    - ctz 12y ago
      I suggest looking at the world beyond your immediate environs. 6 cents vs 6 dollars is the difference between a person in a low-income economy spending 0.1% vs 18% of their income on a website.
      - Mister_Snuggles 12y ago
        That works out to an income of about $33/mo. I think that person has a lot more to worry about than where to host their static site.
- higherpurpose 12y ago
  They do: http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html http://googlewebmastercentral.blogspot.com/2014/08/https-as-...
- nickfox 12y ago
  I have no idea what you people are talking about. All of my websites are https but the problem I have is that Google is NOT serving data from secure servers. Open the chrome console on my webpage here and look at all of the errors and warnings. All because Google refuses to serve secure content despite people complaining for YEARS in the forums. https://www.websmithing.com/gpstracker/displaymap.php https://www.websmithing.com/gpstracker/displaymap.php Can't Google spend a little more time securing their own websites instead of telling everyone else to secure theirs?
zerocrates 12y ago
If you make a change like this too quickly, you run the real risk of users seeing the "warning" so often that they just get trained to ignore it (even more than they already do).
- nkozyra 12y ago
  A fair argument, but what's the gradual approach? It has to be all or nothing. The idea behind this is to use it as an impetus for sites and services to move to SSL/TLS.
  - gojomo 12y ago
    There's a very interesting idea at the end of this proposal: that the more-aggressive warnings arrive based on telemetry of the preponderance of secure interactions. By changing over time, and in a manner sensitive to the real mix of user interactions, there's less risk of habituation to "oh, all sites show that warning". You could even make the switch based not on the entire browsers' usership, but an individual user's recent past. (Not sure this is a good idea, but it's an interesting one.)
  - hrjet 12y ago
    One possibility for a gradual approach: sites which have both HTTP and HTTPS servers, are marked insecure when user browses to the HTTP version. The knowledge about the presence of both HTTP and HTTPS can be hard-coded for popular websites* and/or inferred from history in the client. * I mean popular websites that don't send HSTS header, such as reddit.com. Those that send the HSTS header would anyway be subjected to automatic redirection. PS. We are considering this option in the gngr browser (https://gngr.info https://gngr.info). We are also considering going further and not loading the HTTP page automatically. The user would need to press "OK" to proceed.
  - byuu 12y ago
    > A fair argument, but what's the gradual approach? Site blacklists (a list of sites that should be secure.) Start with all of the banking and payment sites. Then add in sensitive topics to the person's country (eg atheism, homosexuality, piracy, etc.) The list would work a lot like the phishing/malware blacklist. If anyone has the algorithms and data for that, it'd be Google. Of course, they'd then risk it being easier for governments to demand browsers block content for them. So it's a double-edged sword.
alxmdev 12y ago
I hope they'll label mixed content pages the same way as plain HTTP, it might motivate all the big websites that still get this wrong to get their act together.
bonsai80 12y ago
My vote for the icon to use would be a small frown or disappointed face. It's different than the icons for broken https, but still gets the point across that something isn't so great. Here's what I'm thinking of: https://cdn0.iconfinder.com/data/icons/smile-emoticons/78/Emoticons_smile_smiley-03-512.png https://cdn0.iconfinder.com/data/icons/smile-emoticons/78/Em...
- cosacid 12y ago
  It looks too pessimistic. I'm sure it would depress a great deal of people who view it.
- Too 12y ago
  Why not a postcard for insecure and envelope for secured? Might be hard to distinguish in small icons and can be confused with email too easily but otherwise the message should go through. Can't be worse than padlocks with different shades of green as we have today anyway. Does anyone actually understand them? Here on HN i get a gray padlock, on some other site i get a green padlock and on yet another site i get a padlock and a nice fancy badge with the website name in it. Doesn't help that every browser keep changing their looks with regards to this every 6 months also.
justinph 12y ago
This is a great idea, and I say this as the webmaster of many sites that are not secure. I should be forced to get my but in gear and fix that.
general_failure 12y ago
Great move. We also need free/cheap wild card certs.
sleepychu 12y ago
Noooooooo! Why must the entire web be secure? I might run some micro news site for my local church that I update manually with (S)FTP and html files - why on earth should that connection be encrypted. Bad security should be marked as bad. No security is not inherently bad.
- eslaught 12y ago
  I disagree. No security really is as bad as broken security. I'm guessing you think your church website isn't worth securing because it doesn't have any sensitive content. But in a world where surveillance is pervasive, that's not something you should depend on. For example, if religious discrimination were to lead to members of your church being harassed because of their viewing habits, then the argument that the content isn't sensitive doesn't seem so strong anymore.
  - illumen 12y ago
    Securing is different to encrypting. Most tracking of people is done by advertising, and marketing companies. Should we mark all websites with advertising as insecure?
    - eslaught 12y ago
      Ads are first-party content, in the sense that they are under the control of whoever is serving the webpage. One would hope that if the content provider were concerned about privacy, they would not choose to serve ads that violated that privacy. On the other hand, using HTTP would open an otherwise harmless content provider to potential ad-insertion attacks by third parties. So in that sense, HTTPS really does matter here.
    - xorcist 12y ago
      As much as I'd love that (seriously, not advertising per se of course but most types of cross domain tracking), something tells me that initiative is not going to originate from the Chrome team...
  - userbinator 12y ago
randomwalker 12y ago
One of the surveillance attacks pointed out in the post is the NSA piggybacking on advertising cookies. Details in the Snowden leaks were scant, so we did some research to figure out just how far the NSA could go with this technique. Very far, as it turns out. Here's a blog post with a link to our research paper: https://freedom-to-tinker.com/blog/dreisman/cookies-that-give-you-away-the-surveillance-implications-of-web-tracking/ https://freedom-to-tinker.com/blog/dreisman/cookies-that-giv... One of our conclusions was that tracking companies switching to HTTPS would help, but a large majority would have to switch to make any difference, because of the sheer number of trackers (Section 4.1). This proposal or something like it is probably necessary if we're to see that magnitude of change.
jcrites 12y ago
> Secure (valid HTTPS, other origins like (* , localhost, * )); Does this notation refer to any protocol and port on localhost? That's my guess, but the meaning of the notation wasn't immediately clear to me.
zzzcpan 12y ago
Maybe showing the "http-is-insecure" warning in the address bar only when the user fills form inputs?
- robszumski 12y ago
  This would be a great first step, maybe a new T0.5 in the transition plan. Get people on board by securing the data they are sending around, and the secure the pages they are reading later.
- kuschku 12y ago
  But what if the site loads JavaScript from an insecure origin?
comex 12y ago
On a related tangent: In the new secure-by-default world, what happens if a website has some large assets (e.g. video, game files) and would like to opt into caching by any transparent proxies that may be on the user's network? The site could embed hashes of the assets in question, and use ServiceWorker to transparently inject a hash check into any fetches (no matter what HTML thingy initiated them), but I think requests to http: from https: are always blocked as mixed content - let me know if I'm wrong. Also, this would still send things like user-agent, language, any non-secure cookies, etc., and allow the unauthenticated server to set them; it would be good to have a way to opt out of all these things, just sending a minimalist HTTP request instead. Of course, even if these issues are fixed, any system allowing caching of assets must allow tracking of what assets were requested; for some sites this is unlikely to provide much info beyond what the domain name already indicates, but for others it would be best to avoid. On the other hand, if assets have sufficiently distinctive sizes, a proxy might be able to guess this information over HTTPS anyway through simple traffic analysis, so it wouldn't be that harmful to run it over HTTP instead.
- JoshTriplett 12y ago
  One of these days, I'd like to have a scheme for referencing secure third-party content that includes hashes. I'm never going to link to a third-party server for some JavaScript file that could be changed out from under me, but if I can link to it on a CDN along with a sha256 or similar, and have it grabbed from my own server instead if the hash doesn't match, great! I've seen a few attempts at that, but nothing that has actually taken off. It needs an appropriate polyfill, so that in browsers that don't support it, either the content gets downloaded and hashed client-side, or the content just gets downloaded from the same origin. > In the new secure-by-default world, what happens if a website has some large assets (e.g. video, game files) and would like to opt into caching by any transparent proxies that may be on the user's network? The whole concept of a "transparent" proxy will hopefully die in a secure-only world. If you want some server on your network to MITM your traffic (for caching or any other reason), use a non-transparent proxy. (Or, install a CA certificate from your proxy, but hopefully widespread use of certificate pinning will kill that too.)
  - 12y ago
sdrinf 12y ago
Synthesis: Chrome Security Team would like to put :( for all non-secure HTTP connections. With gradual deployment, and increase of all active sites moving to HTTPS, it is assumed that users won't become trained to ignore this as a warning signal. | Then, in the long term, the vendor might decide to represent non-secure origins in the same way that they represent Bad origins. The biggest disadvantage of the proposal, as it stands in current CA climate, is that it's psychologically successfull deployment will impose a liability for site operators to touch their sites at least once per CA renewal timeframe. There are many sites where this isn't desired, feasable, or even possible at all, but which despite non-security, still serves giant heaps of high-quality information. So, this will increase SEO, and accessibility gap between sites run by geeks, and sites (attempted to) run by everyone else. Whether this is a desired future of the web is left to an exercise for the dear reader.
- icebraining 12y ago
  The Let's Encrypt project will have a daemon that automatically renews the certificate.
1stop 12y ago
Even with HTTPS if you compromise the server, or the client you can do whatever you like... so my awesome server with all ports open and with login (on everything): admin password: 123 serves some content, but has a valid certificate, and the browser says: "This Connection Is Secure!" Meanwhile a well managed server with no open ports, private key auth etc, but serves content without HTTPS, the browser says "This Connection Is Insecure!". Seems a bit misguided to me. Also feels a little corrupt and profit driven (by CAs)... Why don't google offer free Certificates... seems an obvious (and trusted) way to spread more "Certified websites".
- chavesn 12y ago
  I'm not sure I follow your argument. You do realize that you are talking about two different kinds of attack channels right? Cleartext-based attacks and snooping (middleman, network peer) are simply far easier and far more likely. You know those happen all the time, right? Literally all the time for certain users in certain places. A cleartext exploit is source-based (or route-based) and the server owner can't ever do anything to fix it besides forcing encryption (or shutting down completely to that source). In contrast, a server compromise is destination-based and will theoretically only exist for the time that it is not known to the server provider.
  - userbinator 12y ago
    On the other hand, cleartext-based attacks are also more easy to detect since the traffic is plainly visible. The maliciousness doesn't always have to be outside, despite all the focus on surveillance recently; and when it isn't, a "secure" connection makes it even harder to detect until it's too late. Here's a recent demonstration of this principle - "smart TVs" phoning home via an unencrypted connection: http://arstechnica.com/security/2013/11/smart-tv-from-lg-phones-home-with-users-viewing-habits-usb-file-names/ http://arstechnica.com/security/2013/11/smart-tv-from-lg-pho... If that was over HTTPS, would such data collection have been as obvious or even discoverable? It would be completely indistinguishable from any other "phoning home" - e.g. to legitimately check for software updates. The same encryption technologies that purport to protect us from mass surveillance... can be used to do it even more stealthily, and this is the main concern I have with making encryption ubiquitous.
hartator 12y ago
I think that can be scary for the wrong reasons. Like a whole part of the web will be marked as "non-secure" where it should be marked as "non-encrypted." Security-wise, MIM (Man in the Middle) attacks using HTTP are a fraction of the real security threats (Phishing that can use https!, Keyloger, Malware, Browser Vulnerabilities...) It will give too much weight to HTTPs websites or too little to HTTP websites. Moreover, SSL certificates are expensive!
illumen 12y ago
Sites with advertising should be marked as insecure. Since they have been known to serve trojans, and also are used to track people without their consent. Will Google and Mozilla both do this? No. Because their revenue depend on it.
- Maxious 12y ago
  Google and Mozilla have no problem blocking sites that use non-Google ad networks as malware http://marketingland.com/googles-chrome-browser-issues-malware-warnings-for-major-news-sites-32520 http://marketingland.com/googles-chrome-browser-issues-malwa...
fiatmoney 12y ago
Excellent. While they're at it, maybe they should stop marking self-signed SSL as more of a security risk than plaintext HTTP.
- bpatrianakos 12y ago
  Yes! I have 4 sites that I bought an SSL certificate for out of around 20 that run. If browsers wouldn't throw a warning for self-signed certificates every last one of my sites would have been secured from the start, easy. The only thing separating a self signed cert from one obtained from a CA is that the CA has some of your contact info but even then it wouldn't take a whole lot of effort to bypass their checks.
  - Matheus28 12y ago
    ...and the CA one actually protects you from MITM attacks (assuming your machine doesn't have nasty root certificates installed).
    - kuschku 12y ago
      You mean nasty root certificates like VeriSign and GoDaddy, which the NSA frequently uses for MitM? You should do the same to those certificates that you did to TURKTRUST, just throw the US CAs out.
      - cbr 12y ago
        VeriSign and GoDaddy, which the NSA frequently uses for MitM? Link?
        kuschku 12y ago
        Snowden, 2013?
        cbr 12y ago
        Actual link? I don't remember reading this in any of the leaked documents and I can't find it now, though I could have missed it.
raldi 12y ago
Can someone explain this part? Secure (valid HTTPS, other origins like (*, localhost, *)); Are parenthesis-asterisk and asterisk-parenthesis some kinds of special origin?
- bzbarsky 12y ago
  In modern W3C and WhatWG specs, an "origin" is either a (scheme, host, port) triple or a nonce value. The asterisks in this case are being used as a shorthand for "any origin which is a triple and whose host is localhost, no matter what the scheme and port are".
Animats 12y ago
From the article: " We’d like to hear everyone’s thoughts on this proposal, and to discuss with the web community about how different transition plans might serve users." ... "You do not have permission to add comments."
- dlisboa 12y ago
  It's pretty obvious they're intending the discussion to happen on mailing lists. We’d love to hear what UA vendors, web developers, and users think. Thanks for reading! We are discussing the proposal on web standards mailing lists: public-webappsec@w3.org blink-dev@chromium.org security-dev@chromium.org dev-security@lists.mozilla.org You make it sound like they're eschewing discussion.
tszming 12y ago
I think this is a good start. But it is also important to educate users that even you are using HTTPS, some companies' internal network might not be fully encrypted and therefore it is not fully secure against some three-letter government agencies :)
michaelbuckbee 12y ago
This seems to describe a situation where sites served over plain 'http' would pop a red 'x' or other distinguishing UI element to connote untrustworthiness. This is almost the case already where a good number of browsers will show no positive (green indicator or lock icon) for domain validated certs - showing a preference for the much more expensive EV (Extended Validation) certs. Screenshots of the different browser SSL level representations: https://www.expeditedssl.com/pages/visual-security-browser-ssl-icons-and-design.html https://www.expeditedssl.com/pages/visual-security-browser-s...
donniezazen 12y ago
I have been looking into setting up SSL for my blog. There currently no free way to get SSL certificates. There are some free ones but they tend to come with strings and lure you into paid plans. I am not sure if this proposal is the best.
- baconner 12y ago
  Today that's true, but hopefully this eff project will turn out next year: https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web https://www.eff.org/deeplinks/2014/11/certificate-authority-...
- rocky1138 12y ago
  SSL Certificates are free. It's the authority you pay for. What needs to change, in addition to this, is the interstitial warning page for a self-signed certificate needs to go away. Having a self-signed cert > http.
  - __david__ 12y ago
    > Having a self-signed cert > http. It really depends on what exactly you are talking about. For a Man-in-the-middle attack, your statement is false. For passive dragnet surveillance, your statement is true. I think people underestimate MITM attacks...
    - TheLoneWolfling 12y ago
      > For a Man-in-the-middle attack, your statement is false. Not with certificate pinning.
    - tomjen3 12y ago
      Doesn't really matter, does it? Even if MITM attacks are 99% of all attacks that doesn't leave you any worse of with a self-signed certificate. Better yet you are able to use a root certificate only trusted by most, rather than all, browsers because you secure that much of your traffic (which could easily be the 80+% that runs a modern browser, just not the few virus infected XP machines) which would enable actual innovation among CAs.
bigeee22 12y ago
Finally...
bigeee22 12y ago
Long overdue. :)
ademarre 12y ago
> We know that people do not generally perceive the absence of a warning sign. Yet the only situation in which web browsers are guaranteed not to warn users is precisely when there is no chance of security: when the origin is transported via HTTP. That is a very strong point. User perception of the browsers' current UX treatments of the various security scenarios poorly represents the true level of security. An insecure HTTP site (no warnings) looks safer than an HTTPS site which happens to reference a single non-HTTPS image (mixed content warning). The absence of a warning for the HTTP site is not fair, because despite the mixed content, data submitted in a web form to the HTTPS site is still encrypted, yet the UX treatment affords it less trust. Separately, how should Extended Validation (EV) certificates fit into this plan? Especially after the final proposed transition phase, T3: Secure origins unmarked. Personally, I think EV certs have become kind of a racket in the CA industry. But they exist nonetheless, and we should push for more consistent browser treatment of site security in general, including consistent treatment of EV certs.
deleted 12y ago
[deleted]
mlaretallack 12y ago
This sounds like a good idea and a step on the right direction. However working in the embedded world, no one has yet created a system for using https that does not involve a lot of complex steps to prevent the browser from warning of an insecure link. It would be nice if all browers worked more like Firefox where it is easier to add exceptions. Going forward I can imagine the conversion I am going to get, "why does the brower say that my traffic controller is insecure?"
ajnin 12y ago
Great. So with this proposal all website operators that don't pay their due to the Certificate Authority cartel will be marked as "bad" sites. I'm all for restoring trust but not before the CA issue is resolved.
josteink 12y ago
This is just pointless scaremongering. Remember what happened when msie added warnings for this a decade ago? People got so fed up with "security"-warnings that they just clicked "OK! OK! Whatever. Get the fuck out of the way!". And they did it to ALL warnings, serious ones too. Glad to see history repeat i itself.
- zerolinesofcode 12y ago
  Agreed. There are so many websites on the internet which do not gather sensitive data from the users but display read-only content.
  - teh 12y ago
    Reading certain articles reveals sensitive information about you, the reader, too. Do you really want every node in the network to know that you like NSFW content or are heavily into my little pony?
    - chippy 12y ago
      Would https be better in that regard? (e.g. tracking of visited URIs by the network)
      - sjy 12y ago
        Yes, because the URI is also encrypted in HTTPS (although it can get leaked in other ways; see the discussion at http://stackoverflow.com/questions/499591/are-https-urls-encrypted http://stackoverflow.com/questions/499591/are-https-urls-enc...).
        dfranke 12y ago
        That thread misses the most important way: the length of the request and the length of the response. On most small sites, the combination of the two will be enough to uniquely identify what page you're visiting.
BrickAddict 12y ago
um...
lnanek2 12y ago
Really not happy with the way Chrome is going on these things. As a web developer, sometimes the best thing for my users is an HTTP media file off a non-SSL CDN closest to their home and cacheable by things like Squid stuck in front of them in my HTTPS otherwise page. But I can't do that now because Chrome will display the page as broken. They are just taking useful tools away from developers to improve the lives of users and not really improving anything except for a few privacy nuts who care about every tiny image on every page possibly being tracked.
- tomjen3 12y ago
  That is easily solvable: make internet connections fast enough that caching is no longer an issue.
  - jacquesm 12y ago
    It is rarely the speed of the connection that makes caching an issue, but much more frequently the cost of the generation of the data and the cost to maintain that data post generation.
jstsch 12y ago
Hmm, there are a lot of sites out there. So many small sites with their own domain name. Local establishments, projects, clubs, communities... that will be hell to migrate, with non-obvious benefits to most site owners. This might force more centralisation of the web again... just move your content to ESTABLISHED_GLOBAL_PLATFORM_X instead of that vhost at SMALL_LOCAL_PROVIDER_Y.
- undefined0 12y ago
  If LetsEncrypt comes pre-installed with cPanel and when creating the domain name it's https by default, then as long as shared hosting providers update the cPanel then all small sites will be updated to be ssl by default. But then we'd have the problem with people continuing to use 'http://' http://' in <a> tags.
cryptolect 12y ago
Ever since I realized there will be a persistent log of my browsing history maintained by one or more government agencies, I have mentally-marked http as risky. I cannot wait for something like this to happen, and encourage the wider less-informed community that TLS is critical for both trust (properly implemented, TLS will provide protection against tampering and data leakage) and to provide a minimum level of privacy (I can see you visited site x, but not what sections of it). Bring it on.
sft 12y ago
Google and others rarely ever mention DNS/DNSSEC, even though just as much information is being sent insecurely in the form of DNS queries/responses. Learn more: https://github.com/jedisct1/dnscrypt-proxy https://github.com/jedisct1/dnscrypt-proxy http://dnscrypt.org/ http://dnscrypt.org/ Check if you already have it enabled (unlikely if this is the first time you're learning about this) http://test.dnssec-or-not.com/ http://test.dnssec-or-not.com/
- kissickas 12y ago
  Is this working for everyone else? I get a "server not found" message. http://downforeveryoneorjustme.com/http://test.dnssec-or-not.com/ http://downforeveryoneorjustme.com/http://test.dnssec-or-not... tells me that the server is up.
  - sft 12y ago
    working fine here there are others to check if you have it (I'm pretty sure you won't unless you have explicitly set it up yourself) google 'DNSSEC test' btw setting up DNSCrypt-proxy takes all of 10 minutes on Windows
edandersen 12y ago
They should also mark as Non-Secure the situation when you are being MITM attacked by your employer - custom root CAs on Windows boxes are quite common.
steve_taylor 12y ago
Marking HTTP as non-secure implies that HTTPS is secure. The large company where I work has quietly rolled out the Zscaler HTTPS proxy and my colleagues are unaware that, despite the assurance given by the green padlock in their browser, their connection is most definitely not secure.
- eli 12y ago
  In that case isn't the problem that their employer installed their own root certificate? The employer could just as well have installed any manner of malware. In the scenario where you are not the administrator of the computer, nothing is secure.
- tomjen3 12y ago
  That is because browsers obey the false root certificate installed locally, even when they otherwise pin the certificate down. This is a deliberate choice, but that doesn't mean HTTPS isn't secure, it means that you can't trust a computer you don't control.
idibidiart 12y ago
Related discussion with and in between W3C TAG members http://lists.w3.org/Archives/Public/www-tag/2014Dec/0098.html http://lists.w3.org/Archives/Public/www-tag/2014Dec/0098.htm...
totony 12y ago
A better approach would be, in my opinion, to only show insecurity when a <form> or user input is requested, i dont really see the use in https everywhere for small static websites. DNS will still leak most of the websites you visit, so anonymity in this case is not really the issue that will be resolved.
- troymc 12y ago
  Here are five reasons why you might want to serve a small static website over https: https://www.bitballoon.com/blog/2014/10/03/five-reasons-you-want-https-for-your-static-site https://www.bitballoon.com/blog/2014/10/03/five-reasons-you-...
- frabcus 12y ago
  It can matter a lot which page you're visiting. Also, DNS can be secured later. When the EFF project to make and update free certificates for everyone launches, there's no reason not to put everything on HTTPS.
  - zzzcpan 12y ago
    Work to install https-capable web server, get and install free certificate and support all that still needs to be done by someone and there is no such someone willing to do it for free for millions of websites. Cost is still significant for majority of websites.
- Confiks 12y ago
  DNS will only leak which hostname you visit, not which pages you access on that hostname. You hereby definitely resolve a privacy issue. Furthermore, the presence of a <form> element also looks like a very bad measure for 'protectworthy' information to me. Websites that require a user session to be established, need users to send a cookie for every request. Those requests need to be secure, or the sessions can be stolen.
  - totony 12y ago
    Then, if there are sessions too, <form> was just an example. You're right for the path though, but for a majority of users, this doesn't matter, that is because a website often has a specific subject (porn, warez, etc), so if one DNS lookups the website, then that pretty much gives it all if the middle man is interested. Read: My opinion is that it's useless for most people, and is problematic for old infrastructures. Therefore there are as much benefit as negative effects, or more negative effects, so it doesn't seem worth it.
jacquesm 12y ago
Since when is HTTPS secure?
demarq 12y ago
Some one explain this to me. If I use Https would I still be protected from my own service providers (isp/carriers). Surely anyone who can see the handshake can also decrypt what follows. I ask this because I'm assuming this move is a reaction to all the NSA buzz that's been in the media(assumption). And I would figure the only way all the spying was going on is because one of the parties we depend on for our internet services anywhere from the ISP to the end server were compromised. So how would HTTPS make a difference?
- jMyles 12y ago
  > Surely anyone who can see the handshake can also decrypt what follows. If I understand your claim here, it seems that you aren't yet familiar with key pair cryptography. It's not enough for someone to witness the handshake - they need to actually possess the 'private' key of one a party in order to decrypt traffic that has been encrypted with that party's 'public' key. It's an amazing feat of mathematics; the fact that it is possible suggests, at least to me, that the physics of the universe in some sense favor the evolution of verifiable private communications. Here's the wikipedia article on key-pair crypto (often simply called "public key crypto"): http://en.wikipedia.org/wiki/Public-key_cryptography http://en.wikipedia.org/wiki/Public-key_cryptography
  - demarq 12y ago
    Thanks!
- cmircea 12y ago
  > Surely anyone who can see the handshake can also decrypt what follows. No. That's the whole point of SSL/TLS. http://security.stackexchange.com/questions/6290/how-is-it-possible-that-people-observing-an-https-connection-being-established-w http://security.stackexchange.com/questions/6290/how-is-it-p...
- totony 12y ago
  NSA doesn't need to mitm you, they just have to ask the IP you are communicwting with what you did.
sft 12y ago
can someone explain how we can save threads within our HN accounts? it's not immediately obvious
IgorPartola 12y ago
To all those arguing that HTTP is still fine, please go ahead and drop ssh in favor of telnet. Go ahead, I will wait. If you cannot figure out why HTTPS is more secure than HTTP and why we should drop HTTP support from all browsers entirely, then please go read about it. HTTP should be used no more than telnet these days. I am not saying HTTPS is perfect as is, but I am saying that HTTP is fundamentally and practically broken at this point. It is exploited daily in many different ways and your and your users' experience is worse because of it. Stop using it, and help other stop. </rant>
cnst 12y ago
So, looking at their screenshots... How about prefixing the non-secure URLs by "http://" http://", so that, you know, people will be sufficiently warned that it's not "https://" https://"?
hobarrera 12y ago
HTTP is not always insecure. Some environments (eg: LAN), can have network-level security (eg: IPSec).

399 points by diafygi 12y ago

Previous discussion in Firefox: https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/iU86qMOwvWs https://groups.google.com/forum/m/#!topic/mozilla.dev.securi... https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 Chromium: https://groups.google.com/a/chromium.org/forum/m/#!topic/security-dev/DHQLv76QaEM https://groups.google.com/a/chromium.org/forum/m/#!topic/sec... https://groups.google.com/a/chromium.org/forum/m/#!topic/security-dev/rGM2oiKZqZU https://groups.google.com/a/chromium.org/forum/m/#!topic/sec...

andrewstuart2 12y ago

I think the best time to do this would be soon after the Let's Encrpyt free CA [1] starts handing out certificates. There's no more good reason not to have HTTPS, so that's a good time to start applying a little pressure and adding the incentive for website authors. Does google already reward secure sites with higher search rankings? I can't decide if I think that's a good idea or not, but if they want to push for a more secure and free web, that's definitely another avenue. [1] https://www.eff.org/press/releases/new-free-certificate-authority-dramatically-increase-encrypted-internet-traffic https://www.eff.org/press/releases/new-free-certificate-auth...

TimWolla 12y ago
> Does google already reward secure sites with higher search rankings? They do: http://googlewebmastercentral.blogspot.de/2014/08/https-as-ranking-signal.html http://googlewebmastercentral.blogspot.de/2014/08/https-as-r...
alexbecker 12y ago
> Does google already reward secure sites with higher search rankings? Yes, although only recently and only slightly. http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html http://googlewebmastercentral.blogspot.com/2014/08/https-as-...
Touche 12y ago
I still haven't heard a reason why it's important that my blog is on https. Waiting.
- abdullahkhalids 12y ago
  There is no reason. Your readers will probably not care that the browser tells them your cat pictures are being delivered to them in a non-secure manner. You shouldn't put in the work to switch over either. But in 2 years it will be easier for you to have a https blog than a http blog and you will naturally switch.
  - MichaelGG 12y ago
    What about when a trusted cat blog starts providing instructions harmful to cats? Or a recipes site sends incorrect information regarding allergies?
- mgraczyk 12y ago
  Some users might want to be sure that the content of your blog as is rendered on their screen is truly the content of your blog. Or perhaps there are users who do not want others to know which specific posts on your blog they have viewed.
  - Touche 12y ago
    Some users might not like my font choice either, but I don't think the browser should judge my site to be inferior because of that.
    - deleted 12y ago
      [deleted]
    - mayneack 12y ago
      If your site has auto-playing sound, would you be opposed to chrome adding the speaker indicator on the tab to alert users that your tab is causing the sound?
Donzo 12y ago
There is a very good reason to not secure your site if you are dependent on ad revenue. When I switched to https, my earnings dropped by about half. I tried it for a week, but I couldn't take the losses. When you have a secure site that uses Adsense, Google only serves ads from secure ad servers. This shrinks the pool of competing bidders significantly. For me to switch back, either Google needs to push advertising networks into securing their ad servers, or the nonsecure warning will have to be really big and scary.
- hashtree 12y ago
  This is a really interesting observation. Can you expand upon what "shrinks the pool of competing bidders significantly" means? For instance, when creating an Ad Words campaign, is there a setting/option that they must opt-in to and if they do not they won't be considered for secure-only advertising?
  - taspeotis 12y ago
    I'm guessing it means that ads that lead to http:// http:// urls get binned.
    - coldtea 12y ago
      No, ads that originate from such urls get binned.
  - Donzo 12y ago
    Here is relevant information about it taken from this page: https://support.google.com/adsense/answer/10528?hl=en https://support.google.com/adsense/answer/10528?hl=en "HTTPS-enabled sites require that all content on the page, including the ads, be SSL-compliant. As such, AdSense will remove all non-SSL compliant ads from competing in the auction on these pages. If you do decide to convert your HTTP site to HTTPS, please be aware that because we remove non-SSL compliant ads from the auction, thereby reducing auction pressure, ads on your HTTPS pages might earn less than those on your HTTP pages."
  - 12y ago
jedberg 12y ago
> There's no more good reason not to have HTTPS Cost. Today I host my website for 6 cents a month as a static page on Amazon S3. To go https, I'd have to first acquire a certificate (lucky that can be free and with Let's Encrypt will be). Then I have to find someone to host that certificate. I can pay someone hundreds to thousands of dollars in setup and monthly fees. Or, the cheapest option I've found is to get a $6/mo VPS as a frontend, put nginx on it, and put my cert there. The problem is that costs 100 times as much as what I pay now, and I have to maintain a server and it's not served from multiple redundant servers like my site is now. Or I can use Amazon's free SNI support, making it so that older browsers can't see my site and I have no way of blocking people from using http or redirecting them. There is currently no good, cheap option to do SSL only that is viewable by everyone. That's why I haven't switched yet.
- coldtea 12y ago
  >The problem is that costs 100 times as much as what I pay now The "100 times as much" is not that impressive, if it merely goes from 6 cents to 6 dollars.
  - egwor 12y ago
    Which in big chunks of the western world is not that much, but it will increase the barrier for entry for many in poorer nations. For commercial sites, then maybe I see a benefit. For everything else... why bother? The info isn't secret, doesn't need to be and since there's so much data going around already is anyone malicious bothering to look?
  - ctz 12y ago
    I suggest looking at the world beyond your immediate environs. 6 cents vs 6 dollars is the difference between a person in a low-income economy spending 0.1% vs 18% of their income on a website.
    - Mister_Snuggles 12y ago
      That works out to an income of about $33/mo. I think that person has a lot more to worry about than where to host their static site.
higherpurpose 12y ago
They do: http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html http://googlewebmastercentral.blogspot.com/2014/08/https-as-...
nickfox 12y ago
I have no idea what you people are talking about. All of my websites are https but the problem I have is that Google is NOT serving data from secure servers. Open the chrome console on my webpage here and look at all of the errors and warnings. All because Google refuses to serve secure content despite people complaining for YEARS in the forums. https://www.websmithing.com/gpstracker/displaymap.php https://www.websmithing.com/gpstracker/displaymap.php Can't Google spend a little more time securing their own websites instead of telling everyone else to secure theirs?

zerocrates 12y ago

If you make a change like this too quickly, you run the real risk of users seeing the "warning" so often that they just get trained to ignore it (even more than they already do).

nkozyra 12y ago
A fair argument, but what's the gradual approach? It has to be all or nothing. The idea behind this is to use it as an impetus for sites and services to move to SSL/TLS.
- gojomo 12y ago
  There's a very interesting idea at the end of this proposal: that the more-aggressive warnings arrive based on telemetry of the preponderance of secure interactions. By changing over time, and in a manner sensitive to the real mix of user interactions, there's less risk of habituation to "oh, all sites show that warning". You could even make the switch based not on the entire browsers' usership, but an individual user's recent past. (Not sure this is a good idea, but it's an interesting one.)
- hrjet 12y ago
  One possibility for a gradual approach: sites which have both HTTP and HTTPS servers, are marked insecure when user browses to the HTTP version. The knowledge about the presence of both HTTP and HTTPS can be hard-coded for popular websites* and/or inferred from history in the client. * I mean popular websites that don't send HSTS header, such as reddit.com. Those that send the HSTS header would anyway be subjected to automatic redirection. PS. We are considering this option in the gngr browser (https://gngr.info https://gngr.info). We are also considering going further and not loading the HTTP page automatically. The user would need to press "OK" to proceed.
- byuu 12y ago
  > A fair argument, but what's the gradual approach? Site blacklists (a list of sites that should be secure.) Start with all of the banking and payment sites. Then add in sensitive topics to the person's country (eg atheism, homosexuality, piracy, etc.) The list would work a lot like the phishing/malware blacklist. If anyone has the algorithms and data for that, it'd be Google. Of course, they'd then risk it being easier for governments to demand browsers block content for them. So it's a double-edged sword.

alxmdev 12y ago

I hope they'll label mixed content pages the same way as plain HTTP, it might motivate all the big websites that still get this wrong to get their act together.

bonsai80 12y ago

My vote for the icon to use would be a small frown or disappointed face. It's different than the icons for broken https, but still gets the point across that something isn't so great. Here's what I'm thinking of: https://cdn0.iconfinder.com/data/icons/smile-emoticons/78/Emoticons_smile_smiley-03-512.png https://cdn0.iconfinder.com/data/icons/smile-emoticons/78/Em...

cosacid 12y ago
It looks too pessimistic. I'm sure it would depress a great deal of people who view it.
Too 12y ago
Why not a postcard for insecure and envelope for secured? Might be hard to distinguish in small icons and can be confused with email too easily but otherwise the message should go through. Can't be worse than padlocks with different shades of green as we have today anyway. Does anyone actually understand them? Here on HN i get a gray padlock, on some other site i get a green padlock and on yet another site i get a padlock and a nice fancy badge with the website name in it. Doesn't help that every browser keep changing their looks with regards to this every 6 months also.

justinph 12y ago

This is a great idea, and I say this as the webmaster of many sites that are not secure. I should be forced to get my but in gear and fix that.

general_failure 12y ago

Great move. We also need free/cheap wild card certs.

sleepychu 12y ago

Noooooooo! Why must the entire web be secure? I might run some micro news site for my local church that I update manually with (S)FTP and html files - why on earth should that connection be encrypted. Bad security should be marked as bad. No security is not inherently bad.

eslaught 12y ago
I disagree. No security really is as bad as broken security. I'm guessing you think your church website isn't worth securing because it doesn't have any sensitive content. But in a world where surveillance is pervasive, that's not something you should depend on. For example, if religious discrimination were to lead to members of your church being harassed because of their viewing habits, then the argument that the content isn't sensitive doesn't seem so strong anymore.
- illumen 12y ago
  Securing is different to encrypting. Most tracking of people is done by advertising, and marketing companies. Should we mark all websites with advertising as insecure?
  - eslaught 12y ago
    Ads are first-party content, in the sense that they are under the control of whoever is serving the webpage. One would hope that if the content provider were concerned about privacy, they would not choose to serve ads that violated that privacy. On the other hand, using HTTP would open an otherwise harmless content provider to potential ad-insertion attacks by third parties. So in that sense, HTTPS really does matter here.
  - xorcist 12y ago
    As much as I'd love that (seriously, not advertising per se of course but most types of cross domain tracking), something tells me that initiative is not going to originate from the Chrome team...
- userbinator 12y ago

randomwalker 12y ago

One of the surveillance attacks pointed out in the post is the NSA piggybacking on advertising cookies. Details in the Snowden leaks were scant, so we did some research to figure out just how far the NSA could go with this technique. Very far, as it turns out. Here's a blog post with a link to our research paper: https://freedom-to-tinker.com/blog/dreisman/cookies-that-give-you-away-the-surveillance-implications-of-web-tracking/ https://freedom-to-tinker.com/blog/dreisman/cookies-that-giv... One of our conclusions was that tracking companies switching to HTTPS would help, but a large majority would have to switch to make any difference, because of the sheer number of trackers (Section 4.1). This proposal or something like it is probably necessary if we're to see that magnitude of change.

jcrites 12y ago

> Secure (valid HTTPS, other origins like (* , localhost, * )); Does this notation refer to any protocol and port on localhost? That's my guess, but the meaning of the notation wasn't immediately clear to me.

zzzcpan 12y ago

Maybe showing the "http-is-insecure" warning in the address bar only when the user fills form inputs?

robszumski 12y ago
This would be a great first step, maybe a new T0.5 in the transition plan. Get people on board by securing the data they are sending around, and the secure the pages they are reading later.
kuschku 12y ago
But what if the site loads JavaScript from an insecure origin?

comex 12y ago

On a related tangent: In the new secure-by-default world, what happens if a website has some large assets (e.g. video, game files) and would like to opt into caching by any transparent proxies that may be on the user's network? The site could embed hashes of the assets in question, and use ServiceWorker to transparently inject a hash check into any fetches (no matter what HTML thingy initiated them), but I think requests to http: from https: are always blocked as mixed content - let me know if I'm wrong. Also, this would still send things like user-agent, language, any non-secure cookies, etc., and allow the unauthenticated server to set them; it would be good to have a way to opt out of all these things, just sending a minimalist HTTP request instead. Of course, even if these issues are fixed, any system allowing caching of assets must allow tracking of what assets were requested; for some sites this is unlikely to provide much info beyond what the domain name already indicates, but for others it would be best to avoid. On the other hand, if assets have sufficiently distinctive sizes, a proxy might be able to guess this information over HTTPS anyway through simple traffic analysis, so it wouldn't be that harmful to run it over HTTP instead.

JoshTriplett 12y ago
One of these days, I'd like to have a scheme for referencing secure third-party content that includes hashes. I'm never going to link to a third-party server for some JavaScript file that could be changed out from under me, but if I can link to it on a CDN along with a sha256 or similar, and have it grabbed from my own server instead if the hash doesn't match, great! I've seen a few attempts at that, but nothing that has actually taken off. It needs an appropriate polyfill, so that in browsers that don't support it, either the content gets downloaded and hashed client-side, or the content just gets downloaded from the same origin. > In the new secure-by-default world, what happens if a website has some large assets (e.g. video, game files) and would like to opt into caching by any transparent proxies that may be on the user's network? The whole concept of a "transparent" proxy will hopefully die in a secure-only world. If you want some server on your network to MITM your traffic (for caching or any other reason), use a non-transparent proxy. (Or, install a CA certificate from your proxy, but hopefully widespread use of certificate pinning will kill that too.)
- 12y ago

sdrinf 12y ago

Synthesis: Chrome Security Team would like to put :( for all non-secure HTTP connections. With gradual deployment, and increase of all active sites moving to HTTPS, it is assumed that users won't become trained to ignore this as a warning signal. | Then, in the long term, the vendor might decide to represent non-secure origins in the same way that they represent Bad origins. The biggest disadvantage of the proposal, as it stands in current CA climate, is that it's psychologically successfull deployment will impose a liability for site operators to touch their sites at least once per CA renewal timeframe. There are many sites where this isn't desired, feasable, or even possible at all, but which despite non-security, still serves giant heaps of high-quality information. So, this will increase SEO, and accessibility gap between sites run by geeks, and sites (attempted to) run by everyone else. Whether this is a desired future of the web is left to an exercise for the dear reader.

icebraining 12y ago
The Let's Encrypt project will have a daemon that automatically renews the certificate.

1stop 12y ago

Even with HTTPS if you compromise the server, or the client you can do whatever you like... so my awesome server with all ports open and with login (on everything): admin password: 123 serves some content, but has a valid certificate, and the browser says: "This Connection Is Secure!" Meanwhile a well managed server with no open ports, private key auth etc, but serves content without HTTPS, the browser says "This Connection Is Insecure!". Seems a bit misguided to me. Also feels a little corrupt and profit driven (by CAs)... Why don't google offer free Certificates... seems an obvious (and trusted) way to spread more "Certified websites".

chavesn 12y ago
I'm not sure I follow your argument. You do realize that you are talking about two different kinds of attack channels right? Cleartext-based attacks and snooping (middleman, network peer) are simply far easier and far more likely. You know those happen all the time, right? Literally all the time for certain users in certain places. A cleartext exploit is source-based (or route-based) and the server owner can't ever do anything to fix it besides forcing encryption (or shutting down completely to that source). In contrast, a server compromise is destination-based and will theoretically only exist for the time that it is not known to the server provider.
- userbinator 12y ago
  On the other hand, cleartext-based attacks are also more easy to detect since the traffic is plainly visible. The maliciousness doesn't always have to be outside, despite all the focus on surveillance recently; and when it isn't, a "secure" connection makes it even harder to detect until it's too late. Here's a recent demonstration of this principle - "smart TVs" phoning home via an unencrypted connection: http://arstechnica.com/security/2013/11/smart-tv-from-lg-phones-home-with-users-viewing-habits-usb-file-names/ http://arstechnica.com/security/2013/11/smart-tv-from-lg-pho... If that was over HTTPS, would such data collection have been as obvious or even discoverable? It would be completely indistinguishable from any other "phoning home" - e.g. to legitimately check for software updates. The same encryption technologies that purport to protect us from mass surveillance... can be used to do it even more stealthily, and this is the main concern I have with making encryption ubiquitous.

hartator 12y ago

I think that can be scary for the wrong reasons. Like a whole part of the web will be marked as "non-secure" where it should be marked as "non-encrypted." Security-wise, MIM (Man in the Middle) attacks using HTTP are a fraction of the real security threats (Phishing that can use https!, Keyloger, Malware, Browser Vulnerabilities...) It will give too much weight to HTTPs websites or too little to HTTP websites. Moreover, SSL certificates are expensive!

illumen 12y ago

Sites with advertising should be marked as insecure. Since they have been known to serve trojans, and also are used to track people without their consent. Will Google and Mozilla both do this? No. Because their revenue depend on it.

Maxious 12y ago
Google and Mozilla have no problem blocking sites that use non-Google ad networks as malware http://marketingland.com/googles-chrome-browser-issues-malware-warnings-for-major-news-sites-32520 http://marketingland.com/googles-chrome-browser-issues-malwa...

fiatmoney 12y ago

Excellent. While they're at it, maybe they should stop marking self-signed SSL as more of a security risk than plaintext HTTP.

bpatrianakos 12y ago
Yes! I have 4 sites that I bought an SSL certificate for out of around 20 that run. If browsers wouldn't throw a warning for self-signed certificates every last one of my sites would have been secured from the start, easy. The only thing separating a self signed cert from one obtained from a CA is that the CA has some of your contact info but even then it wouldn't take a whole lot of effort to bypass their checks.
- Matheus28 12y ago
  ...and the CA one actually protects you from MITM attacks (assuming your machine doesn't have nasty root certificates installed).
  - kuschku 12y ago
    You mean nasty root certificates like VeriSign and GoDaddy, which the NSA frequently uses for MitM? You should do the same to those certificates that you did to TURKTRUST, just throw the US CAs out.
    - cbr 12y ago
      VeriSign and GoDaddy, which the NSA frequently uses for MitM? Link?
      - kuschku 12y ago
        Snowden, 2013?
        cbr 12y ago
        Actual link? I don't remember reading this in any of the leaked documents and I can't find it now, though I could have missed it.

raldi 12y ago

Can someone explain this part? Secure (valid HTTPS, other origins like (*, localhost, *)); Are parenthesis-asterisk and asterisk-parenthesis some kinds of special origin?

bzbarsky 12y ago
In modern W3C and WhatWG specs, an "origin" is either a (scheme, host, port) triple or a nonce value. The asterisks in this case are being used as a shorthand for "any origin which is a triple and whose host is localhost, no matter what the scheme and port are".

Animats 12y ago

From the article: " We’d like to hear everyone’s thoughts on this proposal, and to discuss with the web community about how different transition plans might serve users." ... "You do not have permission to add comments."

dlisboa 12y ago
It's pretty obvious they're intending the discussion to happen on mailing lists. We’d love to hear what UA vendors, web developers, and users think. Thanks for reading! We are discussing the proposal on web standards mailing lists: public-webappsec@w3.org blink-dev@chromium.org security-dev@chromium.org dev-security@lists.mozilla.org You make it sound like they're eschewing discussion.

tszming 12y ago

I think this is a good start. But it is also important to educate users that even you are using HTTPS, some companies' internal network might not be fully encrypted and therefore it is not fully secure against some three-letter government agencies :)

michaelbuckbee 12y ago

This seems to describe a situation where sites served over plain 'http' would pop a red 'x' or other distinguishing UI element to connote untrustworthiness. This is almost the case already where a good number of browsers will show no positive (green indicator or lock icon) for domain validated certs - showing a preference for the much more expensive EV (Extended Validation) certs. Screenshots of the different browser SSL level representations: https://www.expeditedssl.com/pages/visual-security-browser-ssl-icons-and-design.html https://www.expeditedssl.com/pages/visual-security-browser-s...

donniezazen 12y ago

I have been looking into setting up SSL for my blog. There currently no free way to get SSL certificates. There are some free ones but they tend to come with strings and lure you into paid plans. I am not sure if this proposal is the best.

baconner 12y ago
Today that's true, but hopefully this eff project will turn out next year: https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web https://www.eff.org/deeplinks/2014/11/certificate-authority-...
rocky1138 12y ago
SSL Certificates are free. It's the authority you pay for. What needs to change, in addition to this, is the interstitial warning page for a self-signed certificate needs to go away. Having a self-signed cert > http.
- __david__ 12y ago
  > Having a self-signed cert > http. It really depends on what exactly you are talking about. For a Man-in-the-middle attack, your statement is false. For passive dragnet surveillance, your statement is true. I think people underestimate MITM attacks...
  - TheLoneWolfling 12y ago
    > For a Man-in-the-middle attack, your statement is false. Not with certificate pinning.
  - tomjen3 12y ago
    Doesn't really matter, does it? Even if MITM attacks are 99% of all attacks that doesn't leave you any worse of with a self-signed certificate. Better yet you are able to use a root certificate only trusted by most, rather than all, browsers because you secure that much of your traffic (which could easily be the 80+% that runs a modern browser, just not the few virus infected XP machines) which would enable actual innovation among CAs.

bigeee22 12y ago

Finally...

bigeee22 12y ago

Long overdue. :)

ademarre 12y ago

> We know that people do not generally perceive the absence of a warning sign. Yet the only situation in which web browsers are guaranteed not to warn users is precisely when there is no chance of security: when the origin is transported via HTTP. That is a very strong point. User perception of the browsers' current UX treatments of the various security scenarios poorly represents the true level of security. An insecure HTTP site (no warnings) looks safer than an HTTPS site which happens to reference a single non-HTTPS image (mixed content warning). The absence of a warning for the HTTP site is not fair, because despite the mixed content, data submitted in a web form to the HTTPS site is still encrypted, yet the UX treatment affords it less trust. Separately, how should Extended Validation (EV) certificates fit into this plan? Especially after the final proposed transition phase, T3: Secure origins unmarked. Personally, I think EV certs have become kind of a racket in the CA industry. But they exist nonetheless, and we should push for more consistent browser treatment of site security in general, including consistent treatment of EV certs.

deleted 12y ago

[deleted]

mlaretallack 12y ago

This sounds like a good idea and a step on the right direction. However working in the embedded world, no one has yet created a system for using https that does not involve a lot of complex steps to prevent the browser from warning of an insecure link. It would be nice if all browers worked more like Firefox where it is easier to add exceptions. Going forward I can imagine the conversion I am going to get, "why does the brower say that my traffic controller is insecure?"

ajnin 12y ago

Great. So with this proposal all website operators that don't pay their due to the Certificate Authority cartel will be marked as "bad" sites. I'm all for restoring trust but not before the CA issue is resolved.

josteink 12y ago

This is just pointless scaremongering. Remember what happened when msie added warnings for this a decade ago? People got so fed up with "security"-warnings that they just clicked "OK! OK! Whatever. Get the fuck out of the way!". And they did it to ALL warnings, serious ones too. Glad to see history repeat i itself.

zerolinesofcode 12y ago
Agreed. There are so many websites on the internet which do not gather sensitive data from the users but display read-only content.
- teh 12y ago
  Reading certain articles reveals sensitive information about you, the reader, too. Do you really want every node in the network to know that you like NSFW content or are heavily into my little pony?
  - chippy 12y ago
    Would https be better in that regard? (e.g. tracking of visited URIs by the network)
    - sjy 12y ago
      Yes, because the URI is also encrypted in HTTPS (although it can get leaked in other ways; see the discussion at http://stackoverflow.com/questions/499591/are-https-urls-encrypted http://stackoverflow.com/questions/499591/are-https-urls-enc...).
      - dfranke 12y ago
        That thread misses the most important way: the length of the request and the length of the response. On most small sites, the combination of the two will be enough to uniquely identify what page you're visiting.

BrickAddict 12y ago

um...

lnanek2 12y ago

Really not happy with the way Chrome is going on these things. As a web developer, sometimes the best thing for my users is an HTTP media file off a non-SSL CDN closest to their home and cacheable by things like Squid stuck in front of them in my HTTPS otherwise page. But I can't do that now because Chrome will display the page as broken. They are just taking useful tools away from developers to improve the lives of users and not really improving anything except for a few privacy nuts who care about every tiny image on every page possibly being tracked.

tomjen3 12y ago
That is easily solvable: make internet connections fast enough that caching is no longer an issue.
- jacquesm 12y ago
  It is rarely the speed of the connection that makes caching an issue, but much more frequently the cost of the generation of the data and the cost to maintain that data post generation.

jstsch 12y ago

Hmm, there are a lot of sites out there. So many small sites with their own domain name. Local establishments, projects, clubs, communities... that will be hell to migrate, with non-obvious benefits to most site owners. This might force more centralisation of the web again... just move your content to ESTABLISHED_GLOBAL_PLATFORM_X instead of that vhost at SMALL_LOCAL_PROVIDER_Y.

undefined0 12y ago
If LetsEncrypt comes pre-installed with cPanel and when creating the domain name it's https by default, then as long as shared hosting providers update the cPanel then all small sites will be updated to be ssl by default. But then we'd have the problem with people continuing to use 'http://' http://' in <a> tags.

cryptolect 12y ago

Ever since I realized there will be a persistent log of my browsing history maintained by one or more government agencies, I have mentally-marked http as risky. I cannot wait for something like this to happen, and encourage the wider less-informed community that TLS is critical for both trust (properly implemented, TLS will provide protection against tampering and data leakage) and to provide a minimum level of privacy (I can see you visited site x, but not what sections of it). Bring it on.

sft 12y ago

Google and others rarely ever mention DNS/DNSSEC, even though just as much information is being sent insecurely in the form of DNS queries/responses. Learn more: https://github.com/jedisct1/dnscrypt-proxy https://github.com/jedisct1/dnscrypt-proxy http://dnscrypt.org/ http://dnscrypt.org/ Check if you already have it enabled (unlikely if this is the first time you're learning about this) http://test.dnssec-or-not.com/ http://test.dnssec-or-not.com/

kissickas 12y ago
Is this working for everyone else? I get a "server not found" message. http://downforeveryoneorjustme.com/http://test.dnssec-or-not.com/ http://downforeveryoneorjustme.com/http://test.dnssec-or-not... tells me that the server is up.
- sft 12y ago
  working fine here there are others to check if you have it (I'm pretty sure you won't unless you have explicitly set it up yourself) google 'DNSSEC test' btw setting up DNSCrypt-proxy takes all of 10 minutes on Windows

edandersen 12y ago

They should also mark as Non-Secure the situation when you are being MITM attacked by your employer - custom root CAs on Windows boxes are quite common.

steve_taylor 12y ago

Marking HTTP as non-secure implies that HTTPS is secure. The large company where I work has quietly rolled out the Zscaler HTTPS proxy and my colleagues are unaware that, despite the assurance given by the green padlock in their browser, their connection is most definitely not secure.

eli 12y ago
In that case isn't the problem that their employer installed their own root certificate? The employer could just as well have installed any manner of malware. In the scenario where you are not the administrator of the computer, nothing is secure.
tomjen3 12y ago
That is because browsers obey the false root certificate installed locally, even when they otherwise pin the certificate down. This is a deliberate choice, but that doesn't mean HTTPS isn't secure, it means that you can't trust a computer you don't control.

idibidiart 12y ago

Related discussion with and in between W3C TAG members http://lists.w3.org/Archives/Public/www-tag/2014Dec/0098.html http://lists.w3.org/Archives/Public/www-tag/2014Dec/0098.htm...

totony 12y ago

A better approach would be, in my opinion, to only show insecurity when a <form> or user input is requested, i dont really see the use in https everywhere for small static websites. DNS will still leak most of the websites you visit, so anonymity in this case is not really the issue that will be resolved.

troymc 12y ago
Here are five reasons why you might want to serve a small static website over https: https://www.bitballoon.com/blog/2014/10/03/five-reasons-you-want-https-for-your-static-site https://www.bitballoon.com/blog/2014/10/03/five-reasons-you-...
frabcus 12y ago
It can matter a lot which page you're visiting. Also, DNS can be secured later. When the EFF project to make and update free certificates for everyone launches, there's no reason not to put everything on HTTPS.
- zzzcpan 12y ago
  Work to install https-capable web server, get and install free certificate and support all that still needs to be done by someone and there is no such someone willing to do it for free for millions of websites. Cost is still significant for majority of websites.
Confiks 12y ago
DNS will only leak which hostname you visit, not which pages you access on that hostname. You hereby definitely resolve a privacy issue. Furthermore, the presence of a <form> element also looks like a very bad measure for 'protectworthy' information to me. Websites that require a user session to be established, need users to send a cookie for every request. Those requests need to be secure, or the sessions can be stolen.
- totony 12y ago
  Then, if there are sessions too, <form> was just an example. You're right for the path though, but for a majority of users, this doesn't matter, that is because a website often has a specific subject (porn, warez, etc), so if one DNS lookups the website, then that pretty much gives it all if the middle man is interested. Read: My opinion is that it's useless for most people, and is problematic for old infrastructures. Therefore there are as much benefit as negative effects, or more negative effects, so it doesn't seem worth it.

jacquesm 12y ago

Since when is HTTPS secure?

demarq 12y ago

Some one explain this to me. If I use Https would I still be protected from my own service providers (isp/carriers). Surely anyone who can see the handshake can also decrypt what follows. I ask this because I'm assuming this move is a reaction to all the NSA buzz that's been in the media(assumption). And I would figure the only way all the spying was going on is because one of the parties we depend on for our internet services anywhere from the ISP to the end server were compromised. So how would HTTPS make a difference?

jMyles 12y ago
> Surely anyone who can see the handshake can also decrypt what follows. If I understand your claim here, it seems that you aren't yet familiar with key pair cryptography. It's not enough for someone to witness the handshake - they need to actually possess the 'private' key of one a party in order to decrypt traffic that has been encrypted with that party's 'public' key. It's an amazing feat of mathematics; the fact that it is possible suggests, at least to me, that the physics of the universe in some sense favor the evolution of verifiable private communications. Here's the wikipedia article on key-pair crypto (often simply called "public key crypto"): http://en.wikipedia.org/wiki/Public-key_cryptography http://en.wikipedia.org/wiki/Public-key_cryptography
- demarq 12y ago
  Thanks!
cmircea 12y ago
> Surely anyone who can see the handshake can also decrypt what follows. No. That's the whole point of SSL/TLS. http://security.stackexchange.com/questions/6290/how-is-it-possible-that-people-observing-an-https-connection-being-established-w http://security.stackexchange.com/questions/6290/how-is-it-p...
totony 12y ago
NSA doesn't need to mitm you, they just have to ask the IP you are communicwting with what you did.

sft 12y ago

can someone explain how we can save threads within our HN accounts? it's not immediately obvious

IgorPartola 12y ago

To all those arguing that HTTP is still fine, please go ahead and drop ssh in favor of telnet. Go ahead, I will wait. If you cannot figure out why HTTPS is more secure than HTTP and why we should drop HTTP support from all browsers entirely, then please go read about it. HTTP should be used no more than telnet these days. I am not saying HTTPS is perfect as is, but I am saying that HTTP is fundamentally and practically broken at this point. It is exploited daily in many different ways and your and your users' experience is worse because of it. Stop using it, and help other stop. </rant>

cnst 12y ago

So, looking at their screenshots... How about prefixing the non-secure URLs by "http://" http://", so that, you know, people will be sufficiently warned that it's not "https://" https://"?

hobarrera 12y ago

HTTP is not always insecure. Some environments (eg: LAN), can have network-level security (eg: IPSec).