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.

84 comments

  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 BeauHD · · Score: 1

      Perfect timing indeed! ;)

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

      Would ya look at that

    3. Re:Congrats Slashdot! by darkain · · Score: 1

      Holyshit, you're right! The cert for this site is only 2 days old. Didn't even notice until you mentioned it!

    4. Re:Congrats Slashdot! by Anonymous Coward · · Score: 0

      RSS feed still http only though.

    5. Re:Congrats Slashdot! by fustakrakich · · Score: 1

      To me it's a honeypot. I wonder if there is a 'conflict' between the URL and its content :-)

      --
      “He’s not deformed, he’s just drunk!”
    6. 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

    7. Re:Congrats Slashdot! by Anonymous Coward · · Score: 1

      This might help.

    8. Re:Congrats Slashdot! by watermark · · Score: 2

      Unless you're reading on mobile, then it defaults to "m.slashdot.org" over plain http.

    9. Re:Congrats Slashdot! by KiloByte · · Score: 1

      On the other hand, the old DICEy overlords at Sourceforge can't even keep their https working, at least for prdownloads.sourceforge.net.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    10. 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
    11. Re:Congrats Slashdot! by Anonymous Coward · · Score: 0

      DICE no longer owns SF.

      Posted as AC 'cause they didn't yet fix the limits.

      KGIII

    12. Re:Congrats Slashdot! by Anonymous Coward · · Score: 0

      This is something I've wanted to see for about 15 years.

      Congratulations, slashdot, and welcome to the fucking 21st century.

    13. Re:Congrats Slashdot! by Bing+Tsher+E · · Score: 2

      Mobile slashdot has a LOT of issues.

      It's definitely easier to just give up on logged-in browsing over a mobile device and post as AC. I know I do.

    14. Re:Congrats Slashdot! by Anonymous Coward · · Score: 1

      That method of certificate pinning assumes that it will not be tampered with while in transit on the first use. Yes, it works similar to SSH, but unless the web visitor is verifying the certificate signature via an out-of-band communications channel, it's trivial for some hostile entity to intercept the page on the first request and replace that header with their own header. Then continue to MITM the site without the user encountering a rogue certificate error.

      The only sane solution at the moment is either DANE, or some distributed certificate pinning effort.

    15. Re:Congrats Slashdot! by Lennie · · Score: 1

      Obviously at first visit the CA-system still applies, so the certificate was/were issued based on some verification process. So that is a form of out-of-band communication channel. It's the most used channel on the Internet right now. This is just an improvement.

      What a lot of attackers want to prevent is detection and with this system in place, the risk of detection also becomes much higher.

      Anyway, you can also get your site added to the lists that are included in browsers. Chrome and Firefox use that too (obviously in case something breaks it's much harder to change them): https://src.chromium.org/viewv...

      I agree DANE/TLSA is a great solution. But it will take time to before most (if not all) networks at least don't break DNSSEC.

      --
      New things are always on the horizon
    16. Re:Congrats Slashdot! by KiloByte · · Score: 2

      HSTS and HPKP provide provide cookies that, while far more unconvenient to abuse, are enormously more insidious. You can't really block third-party H??? cookies, making them session-only defeats their stated purpose, and usual cookie-handling extensions don't manage them either.

      Thus, anyone who cares about privacy needs to disable both HSTS and KPKP, which is sad as such people tend be those most at risk of state-level attacks.

      So we indeed urgently need DANE. For now, both Chrome and Firefox have it effectively at WONTFIX.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    17. Re:Congrats Slashdot! by Lennie · · Score: 1

      How are they cookies ? How does the server learn what the client/browser knows ?

      The client/browser doesn't send what the it knows to the server and AFAIK there is no Javascript API or similar to check it from within the page.

      --
      New things are always on the horizon
    18. Re:Congrats Slashdot! by Shirley+Marquez · · Score: 1

      The RSS feed doesn't gather any PII (personally identifiable information). There is no compelling reason for it to use HTTPS. The same is true for all the read-only vanity sites out there that don't serve advertising or use passwords.

    19. Re:Congrats Slashdot! by KiloByte · · Score: 1

      You get only 1 bit per hostname but can use any number of them. You then make a query to http://bit0.example.org/ http://bit1.example.org/ http://bit2.example.org/ and so on, recording which succeeded and which failed. For HSTS you query http and have https either not work or return a different answer, for HPKP you query https and have test servers use certificates signed by a valid CA that doesn't match the pin.

      You don't even need javascript to read the answers, both to display something to the user (pieces of CSS) or notify your server (you know whether the test requests succeeded or not).

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    20. Re:Congrats Slashdot! by Lennie · · Score: 1

      I understand your point now. But that's a lot of trouble to go through and it would take a lot of requests to identify a single user. There are much easier and more stealthier ways to do that.

      --
      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 Hentes · · Score: 1, Insightful

      Why is it better to force users to use https instead of letting them choose? I hate this modern trend when removing features is considered "progress".

    2. Re:Google knocks Apple, Bing and Microsoft by NatasRevol · · Score: 1, Insightful

      Adding security is now removing features?

      Fat, drunk and stupid is no way to go through life, son.

      --
      There are two types of people in the world: Those who crave closure
    3. 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.

    4. Re: Google knocks Apple, Bing and Microsoft by Anonymous Coward · · Score: 0

      Mod up please.

      Only force https where necessary

    5. Re: Google knocks Apple, Bing and Microsoft by Shirley+Marquez · · Score: 1

      Apple, Bing, and Microsoft are all sites that collect personal data. They ask you to log in, which means that you are either sending them a password or you already have a cookie. They are in the class of site that should be using HTTPS by default.

      There are many sites that do not collect any personal data. Either they have no login at all, or they have a login procedure where you don't have to provide any significant amount of personal data to get a login credential, just a handle and a password. (That password requirement just serve as an anti-spam measure.) And any posts there are available for public reading without login. Furthermore, if they don't serve ads there is no risk of an injection attack from an ad network.

      There is no compelling reason for a site like that to require HTTPS. Either you are sending no data at all or only data that is of little interest to anybody. The only way to get in trouble by accessing a site like that is if it serves you malware content, which can only happen if the site security has been compromised and somebody has replaced some of its content. Mandatory HTTPS won't save you in that case.

  3. Just one problem by Anonymous Coward · · Score: 1

    Well, not just one problem, but it's a big one, and typically overlooked. It's nice we now encrypt everything, but we're still relying on commercial parties to "verify identity" and to protect us... from anyone they don't take money from. That's a big one, it's fundamental, and it doesn't scale. Worse, any currently in use alternative, like relying on governments, isn't better.

    1. Re:Just one problem by xxxJonBoyxxx · · Score: 1

      >> we're still relying on commercial parties to "verify identity"...it doesn't scale

      Actually, it DOES scale, which is generally why HTTPS (used to provide "one-way" authentication of server identity) thrives on top of its CA-signed X.509 certificates.(As opposed to a point-to-point world in which each user would have to individually trust the credential of every site they visited, like most SSH or PGP implementations.)

    2. Re:Just one problem by Cramer · · Score: 2, Insightful

      Exactly. It's just more theater. 99% of those "cheap" ssl certificates are not validated AT ALL. People are blindly putting trust into a system that has none.

      And on top of this, SSL is an exceptionally expensive computation. It takes rather expensive dedicated hardware to handle at any meaningful rate. (go play with the opensssl speed tool to see for yourself)

    3. Re:Just one problem by Anonymous Coward · · Score: 0

      No, Let's Encrypt exists now. You can easily get free certificates. There's issues with the deployment model that still need to be worked out, but they only matter for large-scale deployments.

    4. Re:Just one problem by Anonymous Coward · · Score: 2, Informative

      It doesn't matter that SSL is computationally expensive, because you don't use it to encrypt the entire session. Instead, you use it to exchange symmetric encryption keys in a secure manner and *those* keys (and algorithms) are what is used to encrypt the session. Even an old Xeon 5160 could encrypt 100-150 MB/s with AES-128 which is enough to keep up with a 1Gbps NIC.

      Modern CPUs are even faster. Those are per-core numbers, so multiple by 4/8/12/16 (however many cores you have).

    5. Re:Just one problem by Cramer · · Score: 0

      The issue is with the initial connection. Setup an https site using just the general purpose cpu and throw a few hundred (or thousand) new connections per second at it. This isn't a problem for Joe Blow's Worthless Internet Hole Blog because it only gets a few dozen new connections per minute (if that.) It's a Real Problem for sites of any real size -- i.e. sites people would give a shit about it being encrypted like banks, paypal, ebay, webmail (eg. gmail), etc. Places like Slashdot... it's just stupid; it's not like there are any secrets here.

      Yes, SSL sessions can be resumed, if the server saved the secret, and the client comes back before the keys expire. Are you connecting to Slashdot every 15min?

  4. 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 Anonymous Coward · · Score: 0

      ^ This.
      Sir, have an internet.

    2. Re:Backing the wrong horse by Anonymous Coward · · Score: 0

      That is why the two functions should be separated. Authentication and encryption are two different things. The certificate should only be used to establish identity and then exchange randomized encryption keys, used for this session only.
      If someone knows of a ways to seamlessly establish identity on a large scale without a trust system, that would be even better.

    3. Re:Backing the wrong horse by iggymanz · · Score: 1

      coercing a CA might be revealing though, wouldn't it be easier to coerce a particular server owner?

    4. Re:Backing the wrong horse by Anonymous Coward · · Score: 0

      Finally some hate for Eric Schmidt around here. God I fucking hate that guy.

    5. Re:Backing the wrong horse by Cramer · · Score: 1

      Or more likely (as in they-are-already-doing-this)... record TB's of encrypted traffic until they can seize the server (and thus the certificate). Once they have the server certificate, they can decrypt every session that has ever been encrypted with it.

    6. Re:Backing the wrong horse by watermark · · Score: 1

      Doesn't "perfect forward secrecy" already do this? This is already available in all modern browsers, it's just up to the servers to implement it. SSL labs only gives A/A+ to servers that implement it.

    7. Re: Backing the wrong horse by ajdlinux · · Score: 1

      That's what we have Perfect Forward Secrecy for.

    8. Re:Backing the wrong horse by Anonymous Coward · · Score: 0

      Three words for you:

      Perfect Forward Secrecy.

      Look it up.

    9. Re:Backing the wrong horse by NatasRevol · · Score: 1

      Can you tell anyone if you get a secret FISA order? No. So how could that be revealing?

      --
      There are two types of people in the world: Those who crave closure
    10. Re:Backing the wrong horse by Anonymous Coward · · Score: 0

      I guess we should explain this briefly.

      Suppose I, Secret Frank, talk to GeoTrust, a CA. I want to snoop Slashdot.org.

      Can I get them to just give me Slashdot's private key? Nope. They don't have it, never did. That's why when you get an SSL cert you use a Certificate Signing Request, rather than having them generate and send you a key like some tu'penny ha'penny PKI a school kid would build.

      So my only option as Secret Frank is to force GeoTrust (or another CA) to issue me a new certificate saying I'm Slashdot.org, using my private key. Then I'll have to MITM the real Slashdot.org constantly, at least for the user I want to snoop.

      Now, by default GeoTrust (or any other big CA) publish everything to the Certificate Transparency log servers. Google invented those. So everybody in the whole can see that the CA published a new certificate, the one I, Secret Frank, wanted. "Look what Secret Frank is doing now". Not subtle.

      Maybe, if I twist arms, I can get GeoTrust to not publish my certificate. But, if the user I want to snoop on uses Google's Chrome browser (or hypothetically other browsers which do this, but today it's just Chrome) it'll know the certificate wasn't published and it can warn the user they're being messed with.

      Now, if I can _really_ twist arms maybe I, Secret Frank, can create my own Internet with just my log servers and my fake web sites on it, and I can keep the user I want to snoop on trapped in that Internet unsuspecting. But that's a lot of hoops to jump through, and if I get any of it wrong the alarm bells start going off immediately.

    11. Re: Backing the wrong horse by Cramer · · Score: 1

      Doesn't apply. With the server key, you can do the exact same math as the server to generate the exact same master secret and decode the entire stream.

      (I've been building systems to do this for over a decade. Sure, it's easier if you happen to be the load-balancer -- i.e. "server" -- in the equation, but out-of-band monitoring of SSL is Very. Real.)

    12. 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.

    13. Re:Backing the wrong horse by shawn2772 · · Score: 1

      That is why the two functions should be separated. Authentication and encryption are two different things. The certificate should only be used to establish identity and then exchange randomized encryption keys, used for this session only.

      That is how it's done in TLS.

      The problem is that a bad cert allows an attacker to "prove" they're the person you want to talk to. So then you exchange random encryption keys with the attacker and proceed to send data. Oops.

    14. Re: Backing the wrong horse by Anonymous Coward · · Score: 0

      Not with PFS enabled. Then two random numbers (one on server and one on client) is generated and used without ever beeing sent on the wire so it's not something that you can sniff with tcpdump and not something that you can recreate later with the private key.

    15. Re:Backing the wrong horse by shawn2772 · · Score: 2

      Doesn't "perfect forward secrecy" already do this? This is already available in all modern browsers, it's just up to the servers to implement it. SSL labs only gives A/A+ to servers that implement it.

      PFS is a step beyond what the AC suggested. The suggestion was that randomized session keys be exchanged for each session, and that is done even without PFS. Without PFS an attacker who records the communication and later obtains the private key of the server can use the private key and the recorded data stream to recover the random session key, and then decrypt the data. With PFS, the attacker must have the private key of the server (or a private key and a corresponding cert that appears to be from that server) and perform a real-time man in the middle attack in order to get the data.

      That's why it's "forward" secrecy. If the attacker can't get in during the communication, he won't be able to get it at any time in the future (unless he can somehow recover the ephemeral key the client used, but clients should destroy those).

    16. Re: Backing the wrong horse by Cramer · · Score: 2

      True ephemeral keys will be an issue, however this does present an avenue for man-in-the-middle compromises. (and has been brought up in various security circles.) To date, only one customer has ever asked why select sessions weren't being processed -- this was a major US University with SSLv1 enabled that was allowing 56bit keys. Those sessions don't use the server key, so we can't decode them. (given a few days, we could recover a single session key, being 56bit DES.)

      Also, computers are very bad at doing anything truly random. While I'm not going to attack any PRNG's any time soon, I'm pretty sure the NSA already does (and likely had a finger or two in a few algorithms.)

    17. Re:Backing the wrong horse by Anonymous Coward · · Score: 1

      That's why we need DANE. Which makes it more difficult for rogue agencies (or rogue CAs) to issue certificates for a particular domain.

      Certificate pinning could also work, but doesn't scale unless it's a distributed lookup service.

    18. Re:Backing the wrong horse by iggymanz · · Score: 1

      you would suck at counter-intelligence. the actions of an agency based CA-level compromise would be different than acting on compromising of individual corporations servers.

    19. Re:Backing the wrong horse by houghi · · Score: 1

      OK, as you seem to be the to-go person on this matter, why do you not tell us what the solution is, how to implement it and what sites use it already and what is being done to have it be used as a standard.

      --
      Don't fight for your country, if your country does not fight for you.
    20. Re:Backing the wrong horse by petermgreen · · Score: 1

      Randomised session specific keys are used in tls.

      Unfortunately the "traditional" ciphersuites establish those keys by having the client generate them and encrypt them with the private key associated the server's certificate. This means that if the private key is later compromised all previous sessions can be decrypted. The DHE and ECDHE cipersuites avoid this problem.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    21. Re:Backing the wrong horse by petermgreen · · Score: 1

      https is not perfect but refusing to use it is a serious case of letting perfect be the enemy of good. Furthermore google has been one of the main driving forces behind the introduction of http key pinning which makes it much harder to perform MITM attacks successfully and much more likely that an organisation attempting a MITM attack will be noticed.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    22. Re:Backing the wrong horse by iggymanz · · Score: 1

      that's why its so much easier to just grab slashdot's private key, assuming anyone ever gave a shit about what was said on slashdot. I"m skeptical myself

    23. Re: Backing the wrong horse by Anonymous Coward · · Score: 0

      Yes, obviously, perfect FORWARD secrecy doesn't work against current attacks. A MITM with the keys is indistinguishable from the actual server.

  5. kick 'em again, harder! by Thud457 · · Score: 1

    Forbes.com:
    Site works on HTTPS Y
    Modern TLS Config N
    Default HTTPS N

    SNRK...
    wait, "Other Top Sites" ?!

    --

    the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff

  6. In before the government shilling starts by Anonymous Coward · · Score: 0

    How DARE companies think they can secure their websites! All https should have breakable encryption provided by the web host so all traffic can be decrypted, at any time, for no probably cause.

    1. Re:In before the government shilling starts by Anonymous Coward · · Score: 0

      Err, you don't need to break https encryption, just get at least of the handful of certificate issuers on board. For example, your browser doesn't know whether the new slashdot.org certificate was issued for SlashdotMedia or a TLA with fake details. If the latter, the TLA can do a man-in-the-middle attack, and your browser will give precisely zero warning.

      SSL/TLS is better than nothing, but the chain of trust is way overrated.

  7. Can we get some love with data at rest now? by Anonymous Coward · · Score: 0

    Now that TLS seems to be well on its way to being time tested, perhaps we can get some standards for DAR encryption that are multiplatform? Right now, the most robust and widely supported standard is the OpenPGP container format. However, it would be nice if a standard like PGPDisk, Apple's sparsebundles, or some other method could be made that works anywhere, be it Android, OS X, or AIX. TrueCrypt/VeraCrypt is OK, but it would be useful if it had the option to support expanding encrypted volumes.

    Even an archive program would be nice. The closest thing I have to storing data at rest securely, with resistance to bit rot via recovery records is either WinRAR, or OpenPGP + PAR2.

    1. Re:Can we get some love with data at rest now? by Anonymous Coward · · Score: 1

      LUKS can have the container grown (though it's a multi-step process including growing the filesystem after growing the container, there is potential for a good UI to be developed to support this) and has at least one application supporting it on windows.

      PAR2 is pretty much the standard for external redundancy. Internal redundancy still risks that a file could be damaged in a way (loss of header) that makes the file unrecognizable, even if it contains redundant blocks inside of it. PAR2 resists this as each blockfile contains its own header with the information needed to rebuild the original file (given sufficient blocks).

      7-zip has support across multiple platforms and supports AES-256 encryption including filenames.

  8. 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.
  9. So when is /. going to use https? by neo-mkrey · · Score: 1

    What? Did I miss something? Has hell frozen over?


    (walks away mumbling something about UTF...)

  10. Re:Enjoy a Haiku by Anonymous Coward · · Score: 0

    LOL

    +1

  11. Multiple domains on the same IP by Anonymous Coward · · Score: 0

    Is this issue solved by now? At least, "good enough" to use it?
    Or is it going to cause issues for those 1% that are still using Windows 95 and similar?

  12. Google must be siding with Criminals and Terrists! by macs4all · · Score: 1

    Of course, that's the ONLY reason why they'd serve over https, right?

  13. Re:Google must be siding with Criminals and Terris by Anonymous Coward · · Score: 0

    Basically, they just want to steal your data before the NSA or hackers do.

  14. When is it going to be free by Anonymous Coward · · Score: 0

    So when are we going to have cert solutions for personal blogs, websites, and small businesses that don't cost an arm and a leg for every day folks?

    1. Re:When is it going to be free by DavidRawling · · Score: 2

      It's called LetsEncrypt. You only have to turn over appropriate access to your server to client software (even though to trust it you'd have to review the code or write it yourself). And your web server has to be able to access the LE servers, so you (currently at least) have to permit outbound access from a device providing the website (there are larger configs where you could mitigate that somewhat but this is the simple case).

      The client hits the LE servers, gets a string to write to a server-specified location (/.well-known/acme-challenge/URI). Oh, and that retrieval by LE is done over HTTP, so there's NO chance that could ever be subverted.

    2. Re:When is it going to be free by tepples · · Score: 2

      Use an ACME client to obtain a domain-validated certificate without charge from the Let's Encrypt CA. If you have a VPS or bigger on its own IP address, you can install the official Let's Encrypt client. If you have shared hosting, you can install the sudo-less client, put the resulting ACME response page at the appropriate well-known URL (instead of running sudo python), grab the certificate, and then file a support ticket with your host to get the installed.

    3. Re:When is it going to be free by JesseMcDonald · · Score: 1

      It seems you have some grudge against Let's Encrypt, but most of your complaints aren't actually true. To begin with, while the webroot verification you referred to is the most common method, DNS verification is also available as part of the ACME standard, with preliminary (but functional) support implemented in Let's Encrypt. For webroot verification the client software does not need to run on the web server itself; the challenge can be met by manually writing the challenge file to the expected location, or the server could simply forward the well-known URI to some other box running the ACME client software. The reference implementation provides some optional auto-configuration logic to make the setup process easier for first-time users, but you don't have to use it. If you do choose to run the client on the web server it can run as an unprivileged user with write access only to the /.well-known/acme-challenge/ directory. Finally, it doesn't matter that the challenge response is transmitted over HTTP, as the one-time-use response token is not a secret and is only used to demonstrate control over the web server currently servicing requests at the domain name listed in the certificate.

      --
      "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
    4. Re:When is it going to be free by Anonymous Coward · · Score: 0

      You don't have to use their client. All you need is write access to /.well-known on the server, openssl (can run offline) and https://gethttpsforfree.com .

  15. 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.

  16. Re:Google must be siding with Criminals and Terris by Anonymous Coward · · Score: 0

    Sort of... They just want to *sell* it to people. That's the root. They want to mine it first and then sell the remnants.

  17. SNI is about 98-99% supported by tepples · · Score: 1

    An X.509 certificate with multiple subjectAltName entries, sometimes called a UCC, works in all browsers but has two drawbacks. First, a multi-SAN certificate may be more expensive to obtain from a commercial certificate authority. Second, a multi-SAN certificate is designed for multiple sites operated by one entity, not a shared hosting environment with a bunch of unrelated sites behind one IP.

    Using multiple certificates on port 443 of one IP address needs Server Name Indication (SNI). This works on both major third-party browsers (Firefox 2 and later and Chrome 6 and later) and all supported pack-in browsers (Safari 4 and later, IE on Windows Vista and later, and Android Browser/Android System WebView on Android 4 and later). The most commonly used browsers without SNI support are IE on Windows XP and Android Browser on Android 2.x, but those have no more than 1% usage share nowadays. I switched my own site away from GoDaddy to a different shared host in the fourth quarter of 2012 for two reasons: GoDaddy openly supported the PROTECTIP bill, and GoDaddy didn't offer SNI at the time.

  18. Re:Encrypt this by secretsquirel · · Score: 0

    cGn3gVMBITAhITAhLSOBib7DmavG+f6Y

    AES key = secretkey

  19. oh yeah google? by csumpi · · Score: 1

    Oh yeah google? Really want https everywhere? How about start signing some SSL certs for free to put the mofreking CA mob out of business?

    1. Re:oh yeah google? by Cyphase · · Score: 0

      Have you heard of Let's Encrypt. It wasn't started by Google, but they're a supporter through Chrome. Let's Encrypt just issued it's millionth free certificate, with those million certs covering 2.4 million domains.

      --
      by Cyphase ( 907627 )
  20. HTTPS ? Why the heck use it on /. ? by Anonymous Coward · · Score: 1

    As in the subject line: Why the heck does /. thinks it should be using it. There is absolutely nothing going on here for me, as a reader and occasional poster, to warrant it.

    I definitily start to dislike all those "lets go with the times" sites who think that their informative articles, jokes and/or cat videos need to be send over HTTPS only. Where is my choice in the matter ?

    Interception (MITM) attacks are only usefull if either side is doing something that needs to be kept secret, and where its value has a meaning. AFAICS nothing /. is doing is of such a value (but if desired posting could be done over HTTPS -- it would be meaningless for AC's though)

  21. Re:HTTPS ? Why the heck use it on /. ? by Anonymous Coward · · Score: 0

    Which is the design intention. We are going to drown the Three Letter Agencies in encrypted content and make their lives difficult. Even if they can devote the resources to cracking it all, they will discover that all that traffic is:

    35% Facebook posts, Tweets, Flirts, OMG my BFF and I were so wasted, and celebrity gossip
    32% porn
    26% internet cat videos, selfies, "junk" shots and food porn
    7% real work
    0.00000000001% terrorist plotting, criminal activity, etc.

    A fact that they are probably already familiar with. However as long as they cannot determine which is which prior to decrypting that traffic then we'll call it a win and go for brewskis.