Slashdot Mirror


How Far Have We Come With HTTPS? Google Turns On the Spotlight (networkworld.com)

alphadogg writes from an article on NetworkWorld: HTTPS is widely considered one of the keys to a safer Internet, but only if it's broadly implemented. Aiming to shed some light on how much progress has been made so far, Google on Tuesday launched a new section of its transparency report dedicated to encryption. Included in the new section is data highlighting the progress of encryption efforts both at Google and on popular third-party sites. "Our aim with this project is to hold ourselves accountable and encourage others to encrypt so we can make the Web even safer for everyone," wrote HTTPS evangelists Rutledge Chin Feman and Tim Willis on the Google Security Blog.

10 of 84 comments (clear)

  1. Congrats Slashdot! by gQuigs · · Score: 5, Insightful

    This is the first time one of these stories have come up and slashdot has had HTTPS enabled!

    1. Re:Congrats Slashdot! by whipslash · · Score: 3, Funny

      Would ya look at that

    2. Re:Congrats Slashdot! by iggymanz · · Score: 4, Informative

      SSLLabs gives A rating

      Protocols
      TLS 1.2 Yes
      TLS 1.1 Yes
      TLS 1.0 Yes
      SSL 3 No
      SSL 2 No

      Protocol Details
      DROWN (experimental) No, server keys and hostname not seen elsewhere with SSLv2
      (1) For a better understanding of this test, please read this longer explanation
      (2) Key usage data kindly provided by the Censys network search engine; original DROWN test here
      (3) Censys data is only indicative of possible key and certificate reuse; possibly out-of-date and not complete
      Secure Renegotiation Supported
      Secure Client-Initiated Renegotiation Yes
      Insecure Client-Initiated Renegotiation No
      BEAST attack Not mitigated server-side (more info) TLS 1.0: 0xc014
      POODLE (SSLv3) No, SSL 3 not supported (more info)
      POODLE (TLS) Inconclusive (Timeout) (more info)
      Downgrade attack prevention Yes, TLS_FALLBACK_SCSV supported (more info)
      SSL/TLS compression No
      RC4 No
      Heartbeat (extension) No
      Heartbleed (vulnerability) No (more info)
      OpenSSL CCS vuln. (CVE-2014-0224) No (more info)
      Forward Secrecy With modern browsers (more info)
      ALPN No
      NPN No
      Session resumption (caching) No (IDs assigned but not accepted)
      Session resumption (tickets) No
      OCSP stapling No
      Strict Transport Security (HSTS) No
      HSTS Preloading Not in: Chrome Edge Firefox IE Tor
      Public Key Pinning (HPKP) No
      Public Key Pinning Report-Only No
      Long handshake intolerance No
      TLS extension intolerance No
      TLS version intolerance No
      Incorrect SNI alerts No
      Uses common DH primes No, DHE suites not supported
      DH public server param (Ys) reuse No, DHE suites not supported
      SSL 2 handshake compatibility Yes

      Miscellaneous
      Test date Wed, 16 Mar 2016 19:51:39 UTC
      Test duration 125.443 seconds
      HTTP status code 200
      HTTP server signature Apache/2.2.3 (CentOS)
      Server hostname star.slashdot.org

    3. Re:Congrats Slashdot! by Lennie · · Score: 3, Interesting

      You know what is good about HTTPS these days:

      - HTTP/2 using HTTPS is faster than HTTP/1.x without HTTPS and it's getting easier to deploy it. For example by using the H2O webserver ( https://h2o.examp1e.net/ ) as a proxy, it comes with built in SSL/TLS library for easier deployment and support for replicating sessions.

      HTTPS itself is becoming easier to deploy and manage:

      - HTTPS doesn't need a dedicated IP-address any more (older browsers/operating systems had problems with the HTTPS equivalent of 'virtual hosts'):
      https://en.wikipedia.org/wiki/...

      - certificates are available for free with an automatic request and renewal system. So no more messing around, you can automate it. -> with Let's encrypt Beta: https://letsencrypt.org/ and for example with acmetool: https://hlandau.github.io/acme....

      There are finally ways to fight the silly CA-system, not completely, but things are improving.

      For regular visitors on a site you can add headers which will prevent an other CA issuing a rogue certificate for your site.
      https://developer.mozilla.org/...

      --
      New things are always on the horizon
  2. Google knocks Apple, Bing and Microsoft by xxxJonBoyxxx · · Score: 4, Informative

    Better link to "other sites" report: https://www.google.com/transparencyreport/https/grid/?hl=en

    Notice that Apple, Bing and Microsoft are all knocked for NOT running a "Modern TLS Config" and NOT using HTTPS by default. (I actually had to check that for myself - it was hard to believe that major companies are still NOT doing HTTPS by default - I enforce this even on my little podunk sites - but it was true!)

    1. Re:Google knocks Apple, Bing and Microsoft by DavidRawling · · Score: 4, Insightful

      And because we need to ~double the amount of data used by all the hamster forums, cat videos and aircraft curation guides, especially when a lot of the world's users are on slow or data-limited connections?

      Look. I get that it's good to ensure that there's no injected content, and that you know you're connected to the site you want - but that's only true for 1% of the population. The rest of the world wouldn't know the difference between https://www.example.com/member... and https://www.example.com.member.... Both "secure" because they're HTTPS, right?

      Factor in all the browsers deciding that privately-signed sites are worse than plain http, that no-one needs to actually SEE the protocol, or the URL, that all the certs are issued by a cabal of companies who just see the benefit of charging for a NUMBER, but barely doing validation ... but sure. "Adding security". Right.

  3. Backing the wrong horse by ickleberry · · Score: 3, Interesting

    HTTPS isn't that safe. Any agency that can coerce one of the numerous CA's can snoop traffic quite easily. Of course Eric Schmidt is an avid fan of the surveillance society so thats why they weren't going to back anything less centralised than CA-based HTTPS

    1. Re:Backing the wrong horse by shawn2772 · · Score: 3, Interesting

      HTTPS isn't that safe. Any agency that can coerce one of the numerous CA's can snoop traffic quite easily.

      While your concerns are real, I think they're overstated.

      A coerced CA cert does allow MITM attacks, but they have to be used very carefully and on a targeted basis, because if they're used too broadly it will be noticed. A TLS MITM attack is very noticeable to anyone who is looking. Google Chrome has caught a few subverted CAs now, thanks to certificate pinning of intermediates for Google, Verisign, GeoTrust and some others. Firefox pins large numbers of intermediates, for lots of domains. I think other browsers are also getting into it.

      Of course Eric Schmidt is an avid fan of the surveillance society so thats why they weren't going to back anything less centralised than CA-based HTTPS

      Nice cheap shot. In fact Google has a couple of significant projects to address the shortcomings of the CA system. One is to increase pinning, but that's kind of a hack. The other is the Certificate Transparency project, which aims to ensure that any certificate produced by any CA for any domain is visible to the owner of that domain. If that succeeds covert certificate issuance will be impossible.

      At bottom, the problem with the CA isn't centralization, it's more complicated than that. The CA system is decentralized in the sense that there are many CAs... but that makes every one of them a single point of failure. In some ways we'd be safer with a truly centralized CA system, because then we'd have one single point of failure rather than a few hundred. The semi-decentralized system we have is pretty decent... if we can enable the world to easily recognize improperly-issued certificates. Certificate Transparency is one good way to do that. I'm also a fan of the Convergence system, but in addition to the existing CA system, rather than as a replacement.

      In any case, although the CA system has some issues, and we have seen a handful of cases where they've been exploited, by and large it works very well, securing more connections and more data than anything else ever has. We'd be foolish to replace it, but augmenting it to address the problems is a good idea.

  4. googles ultimate end goal is far more impressive. by nimbius · · Score: 4, Informative

    Google, er, Alphabet didnt really get a rock in their shoe about encryption until Edward Snowden so lets take a moment to thank their engineering consultant in Russia. Once it was revealed that the US government had placed secret taps on links between google datacenters to render their endpoint to service encryption meaningless, the company began working to make the internet a living hell for the surveillance state.

    Google owns a browser, so that browser adopted SSL, then TLS as a mandatory connection parameter for google services. a pretty good share of Mozilla, at least in braintrust, is owned by Google and so getting firefox to endorse and enforce encrypted channels to google and other web services was childsplay. after a year, the titty got tougher and HSTS was the norm on some of the largest web content providers on the internet. SSL had been completely phased out for TLS 1.2 and strong AES256 crypto in light of a more concerned review of open source encryption after the governments audacious claim they could break in excess of 80% of encrypted traffic. Libressl hit the scene after some disclosures, DEFCON changed their status with US law enforcement to "its complicated" and now in this foul year of our lord 2016, uncle sams up proverbial shits creek with Apple in what will either be a resounding defeat, or a knock-down drag out multi decade battle at the hands of a corporation with more income and assets than most foreign nations. But slashdot, its only getting good.

    googles set their target to the next generation of encryption, elliptic curve, and its looking to be a trend-setter. the primes used by most current elliptic are cooked up by NIST, and NIST has in the past been implicated in weakening encryption as part of US security policy. NIST primes are still used in chrome, but chrome supports Dan Bernsteins Curve25519 alternative that isnt intentionally gimped for uncle sam. Look for Google --and the internet-- to begin using this and other "safe curves" as standards to replace secp384r1 and prime256v1. devices and services in the year of the hoverboard are now shipping with encryption as a requirement, not an option, and features to disable it in browsers have been quietly retired. And perhaps the most resounding confirmation of the internets collective "fuck you" against the carte-blanc collection of data on citizens has come from outside the US. a majority of VPN and encrypted storage providers do not reside within the immediate jurisdiction of Washington.

    --
    Good people go to bed earlier.
  5. Re:googles ultimate end goal is far more impressiv by shawn2772 · · Score: 4, Informative

    Google, er, Alphabet didnt really get a rock in their shoe about encryption until Edward Snowden

    While I think we should all be very grateful for Snowden's revelations, that's not true. Google was really serious about encrypting everything long before Snowden's revelations.

    For example, Gmail was the first major webmail service to provide users the option of only using SSL, back in 2008 or so. Google turned on SSL for web searches in 2011. The design of SPDY, later adopted by the IETF as HTTP2, started around 2010 and from the beginning had no unencrypted mode (though the IETF insisted on adding one).

    Once it was revealed that the US government had placed secret taps on links between google datacenters

    Google actually started work on encrypting all of those data center links long before Snowden's information came out, though Snowden definitely did light a fire under the project, causing it to get fully deployed very quickly. Snowden probably also had a lot to do with Google's decision to completely disable non-TLS traffic for many of their services (IIRC it was 2014 when gmail and search went TLS-only).

    Google owns a browser, so that browser adopted SSL, then TLS as a mandatory connection parameter for google services.

    Chrome supported SSL and TLS before Snowden, and ownership of Chrome had nothing to do with making encryption mandatory for Google services, which was done in a browser-agnostic way. Chrome did provide a platform for Google to experiment with other improvements, though, such as certificate pinning, SPDY and QUIC. SPDY and QUIC are mostly about performance, but as I mentioned above Google build encryption into them from the ground up and never even bothered with unencrypted versions.

    after a year, the titty got tougher and HSTS was the norm on some of the largest web content providers on the internet.

    HSTS also predated Snowden, and Google even started using it for some services before Snowden. But, yes, again Snowden spurred much wider adoption. Which is awesome.

    But slashdot, its only getting good.

    Indeed. All new Internet protocols and standards now specifically address anti-surveillance in their designs, and lots of academic research is focused on new technologies to make surveillance hard. This is actually an even bigger change than the TLS push, etc., indicates. Prior to Snowden, preventing surveillance was not a design goal. If it happened, it happened by accident. No more. It's now a design goal for much of the tech industry.