back to article Microsoft sets Feb 2017 date to kill last SHA-1 zombies

Microsoft has posted the next step in its deprecation of SHA-1 certificates, but they'll survive for nearly another year. Back in November, Redmond was mulling joining Firefox in a death-to-SHA-1 party during 2016, but its latest missive sets a February 2017 sunset. At that date, Microsoft's Edge Team writes, both Edge and …

  1. Anonymous Coward
    Anonymous Coward

    Quis custodiet ipsos custodes?

    I think it's really cute how they keep up this pretence of security, when the entire operating system is a piece of surveillance apparatus.

    1. Phil Kingston

      Re: Quis custodiet ipsos custodes?

      Get out much?

      1. Anonymous Coward
        Anonymous Coward

        Re: Quis custodiet ipsos custodes?

        You feel the need to resort to ad hominem because deep down you know it's true. All your telemetry is being streamed to Microsoft, and that's being shared with the NSA as per all PRISM members.

        This is the part where you counter with: "I have nothing to hide / They wouldn't be interested in my lowly information anyway".

        1. Phil Kingston

          Re: Quis custodiet ipsos custodes?

          If I used Windows...

        2. Anonymous Coward
          Anonymous Coward

          Re: Quis custodiet ipsos custodes?

          What's a PRISM "member"? ALL companies (well certainly ones that are based in or trade in the US) have to comply with PRISM information demands. You make it sound like Microsoft have signed up to do this for fun! By all means share around honest information about the $h1t they - and ALL big companies - do, but don't go making up stuff they don't; you just make your arguments specious.

        3. Anonymous Coward
          Anonymous Coward

          Re: Quis custodiet ipsos custodes?

          >> This is the part where you counter with: "I have nothing to hide / They wouldn't be interested in my lowly information anyway".

          No. This is the part where we counter with "shut up - you're an idiot"

    2. Anonymous Coward
      Joke

      Re: Quis custodiet ipsos custodes?

      Still, MS needs to protect the telemetry transmission properly...

    3. Lunatik

      Re: Quis custodiet ipsos custodes?

      Plumbum album galerum, multa?

    4. Timmy B

      Re: Quis custodiet ipsos custodes?

      "I think it's really cute how they keep up this pretence of security, when the entire operating system is a piece of surveillance apparatus.".....

      Anybody that goes online at any time has no basis to complain about surveillance. If anyone with the staff and budget of a nation state wants to watch you then they will.

  2. Ken Hagan Gold badge

    Yes, we admit it. Deep down, we know that our bank passwords are streamed to the NSA by the Microsoft keylogger. You can see it clearly if you run wireshark on a network segment between a PC and the wider internet, but the Lizard people come in the night and erase your brains so you never report it.

    (Oh, and case it isn't obvious to the casual reader, all MS employees *are* Lizard people, so they don't blab either.)

    1. Geoffrey W

      Hey! I'm Lizard People and all this is news to me. Is there some Meta Lizard conspiracy going on here that I'm being left out of? Bastard Lizards!!! Cant trust no-one...

  3. Anonymous Coward
    Anonymous Coward

    Certificates are the illusion of security

    Your browser trusts root and intermediate CAs. Think about it. Why? Is there any evidence these have not had their public keys shared with the spooks. No need to break any SSL protocol or cypher if you have the key to decrypt it all.

    1. Anonymous Coward
      Anonymous Coward

      Re: Certificates are the illusion of security

      It looks you have no clue about how certificates and SSL/TLS work. Also, public keys are shared with everybody, hence the name "public"... even with a CA private key you can't decipher anything - you can issue spoofed certifcates, that's true...

    2. Lee D Silver badge

      Re: Certificates are the illusion of security

      The root and intermediate CA's do not encrypt any data. Sure, they might be able to sign anything, but they aren't the password to your data even if you "trust" them.

      But the CA's you do use to actually encrypt data (well, almost, but DH really arranges those keys and the CA is used to ensure you're actually connected to, for instance, facebook.com etc.) are published in open directories now which your browsers can check against so you can be sure that they haven't been mis-signed by even their own CA in order to subvert the process. It's called certificate transparency (along with things like certificate pinning).

      Note that at no point do you ever send your server's private key to a certificate authority. It doesn't work like that.

      Therefore, although they COULD in theory sign a fake cert of their own and have it accepted by some browsers as being valid credentials for your site and then man-in-the-middle your server so that they accept connections with THEIR generated private key instead of yours, almost any modern browser will throw a fit when they try this. In the same way that someone in an Indian CA once generated a cert for google.com to try to intercept it and it was spotted, blacklisted and the CA blacklisted too because it wasn't GOOGLE's choice of CA. And if it had been but the private key was different (i.e. not from Google), the same would have happened.

      Honestly, CA's do a worthless job. That's why LetsEncrypt can do what it does for free. It literally just says "I have seen evidence that this person probably does own facebook.com and I attest to it with this signature". Any browser that trusts that without checking against the user, previous sessions to that same website and/or certificate transparency services really isn't worth browsing on.

      But, please, keep spreading the FUD.

      (P.S. Yes, I took your "public key" to actually mean "private key" given the context because, as pointed out, public keys are... well... public. You literally give them away to anyone and everyone, that's kind of the point of them. But your private key NEVER LEAVES YOUR SERVER, not even to get an SSL certificate request signed).

      1. Anonymous Coward
        Anonymous Coward

        "CA's do a worthless job"

        Just because they are let issuing certificates without any proof of "ownership". Just like it happened to domain names.

        Actually, a CA should have been forced to properly vet a certificate application before issuing it, because certificates imply authentication, not encryption only (and encryption without authentication is still risky).

        You can't rely on browser pinning for that, because, once again, your bound to a commercial entity who pins what it likes. Google may pin its one certificates in Chrome, others may not.

        Unluckily, mean business reason prevailed (just like domains), and there's not CA liability for whatever they issue, unless the problem is so big they start to be removed by browsers.

        Extended validation certificate are something in that direction, but how much the vetting process is good I really don't know. Just the vetting process costs, and people don't want to pay for security. And now LetsEncrypt is selling them, for free, the illusion that encryption can work with lame authentication...

      2. bombastic bob Silver badge

        Re: Certificates are the illusion of security

        "Therefore, although they COULD in theory sign a fake cert of their own and have it accepted by some browsers as being valid credentials for your site and then man-in-the-middle your server so that they accept connections with THEIR generated private key instead of yours, almost any modern browser will throw a fit when they try this."

        etc,

        very true. I've been deep into researching cert-land over the last ~2 weeks (and some prior). A summary of what I've found: you can be your own CA, but you have to load the root (and other) certs onto the target machines somehow (let's say an application installer program, like the one I recently open sourced). Like with a self-signed cert, however, you throw warnings in web browsers.

        Internet Explorer uses Windows' system cert store, and you can have an application installer (let's say) install new root certs to prevent warnings. Incidentally, this can happen without your knowledge from any application running with 'Admin' privs, calling the right functions.

        Firefox and other browsers often have their OWN cert stores separate from the OS, so you'll have to get past THEIR security and warnings to load new root certs.

        Intarweb filtering appliances often use the 'MITM' technique as part of their operations (did you mention those? I might've missed it), so IT people must load the appliance's root certs on everyone's workstation by policy or manually [whichever].

        As for code-signing, kernel drivers require a "microsoft signature" to load from bootup, but they can dynamically load after boot using regular signed certs (so load your root and signing certs and your drivers will work post-boot, but not during boot). Enabling 'self cert' lets you test things, but apparently shuts off DRM-related things. Not like I need them...

        Microsot has also added an even BIGGER "tollbooth" with regards to signing requirements in windows 10, allegedly for quality assurance, but most likely to put even BIGGER roadblocks and tolls in place for independent devs and open sourcers, and maybe lock us into all using windows 10 and playing by THEIR rules forever. That's my opinion, ok.

        As for web site certs, self-signs work, but throw a warning (typically) as you pointed out. If you accept the cert by ignoring the warning, https will work just fine like it was meant to be.

        openssl can create certs easily, and there are several good online resources on how to do this (including my own web page on being your own cert authority). So yeah, the info is a search engine away. code-signing resources go through Microsoft's "circle jerk" documentation hell, so it's harder to find THAT information without time and frustration.

        And related, MS's own examples for code signing self-certs actually create certs that use sha1. But sha256 works fine for code signing certs as far as I can tell (creating my own, of course). But I did see some odd behavior in the kernel debug output in Win 7 checked build when using sha256, some assert about the hash length being larger than some value...

        hopefully not 'too long' forcing 'did not read'

    3. bombastic bob Silver badge

      Re: Certificates are the illusion of security

      "Is there any evidence these have not had their public keys shared with the spooks. No need to break any SSL protocol or cypher if you have the key to decrypt it all."

      um, I don't think you understand the following very well:

      a) public/private key encryption

      b) SSL protocol handshaking

      c) certificate signing and how it authenticates a web site

      the public keys in the certs have little to do with SSL protocol, but (as I understand) they're used for validating the signatures, sort of like the way a hashing algorithm can validate a logon and password without revealing the password.

      So there's no decryption with a public key. only ENcryption. then you could match the encryption to a known result (I'm assuming) to validate it.

      The SSL protocol uses different methods, among them Diffie-Hellman. Time to google if you haven't heard of it.

      Or I can simply point you to it: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

      so even if you had a cert's private key, you wouldn't be able to use it to decrypt SSL traffic.

  4. Anonymous Coward
    Anonymous Coward

    > a CA should have been forced to properly vet a certificate application before issuing it, because certificates imply authentication

    No they don't. A standard HTTPS server certificate attests that the holder of a given private key is also the owner of a particular domain - nothing more. In particular it asserts nothing about the identity of the owner.

    An EV certificate may attest to the legal identity of the owner - e.g. "Bank of Foobar Inc". But that's very much an optional layer.

    1. bombastic bob Silver badge

      "A standard HTTPS server certificate attests that the holder of a given private key is also the owner of a particular domain - nothing more. In particular it asserts nothing about the identity of the owner."

      not quite accurate. the server certificate is supposed to match the IP address and/or domain of the server, and be signed by an authority [self-signing works if you allow it to when prompted by the browser] to authenticate the cert itself. As I recall, the CN needs to be the domain name for a server cert. There's a lot of discussion about this online, so it's easy to find. You can use openssl to be your own CA and issue your own server certs. Or you can use cacert.org. But their root cert isn't on Microsoft's OSs by default (or I haven't seen it, at least), so you'll have to load the root cert, and then all of their issued certs will be trusted. That's basically how it works.

      so the cert doesn't determine the SSL encryption. It simply validates that the web site in question is who they say they are, and not some man in the middle trying to read your encrypted traffic.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like