61–70 of 100 posts
The problem i have with their "neutral, lacking security" icon is that it does not indicate that anything is wrong when in fact there is. https:// should never have a neutral icon. it should be VALID or INVALID.
Heh, maybe they could extend it to self-signed being neutral...
Earlier quoted context omitted.
While I'm a huge fan of what you're doing in terms of crypto at Google, it's hard for me to see this decision as anything other than reckless. I think we'll be able to show a number of empirical examples of how, over the coming months, it will make the web a less secure place as sites that we're just now starting to convince to adopt crypto will stop. I do at least hope that you will make efforts to alert more of the…
Unfortunately we don't have the technical ability, nor do people have the mental capacity, to cope with multiple URL schemes for different "levels" of security. SHA-1 limits the security for everyone and all uses. And if sites are worried about compat, Google will be doing this transition along with everyone else. That's a good tailwind to ride. If Microsoft's 2016/2017 deadline is reckless, what SHA-1 deprecation da…
If you are returning two different certificates for two different situations at Google.com, the least you could do is dedicate some of your vast engineering resources to making the plugins to support such a setup production ready. If Google uses it's technical sophistication to avoid the pain while the rest of the web burns then that's, at best, hypocritical.
I'll make you this deal: if you do it for Apache, we'll do it for NGINX. That's the right thing to do. As would be making SSL certs free, but that's a conversation for another day.
I'm concerned that the net effect of this will be to make the Internet less secure. In most cases, webmasters will be forced to make a Faustian choice: live with the scary warning in Chrome for modern users or give up support of browsers running on Windows XP (pre-SP3) and early versions of Android (pre-2.3), since they don't support certificates with a more secure hash than SHA1. We'll likely write a blog post soon…
The world will be switching to SHA-256 - Microsoft already decided that last November [1]. This is just Chrome helping out. Obviously, XP is a problem. We're planning on prompting Chrome users on affected versions to update, both at startup and on the error page. SP3 does exist and one doesn't need to pass the Genuine Windows check to install it[2] so I think we have a good chance to getting users to update once site…
Earlier quoted context omitted.
You say that Google will be doing this transition along with everyone else, but you won't be feeling the same pain. Google's current cert expires November 24th, 2014, so when you extend it then it will be for 1 year and your new cert will expire before January 1st, 2016 which is pretty convenient for you because that cert (even if it is SHA-1) will still show up as a green bar through Chrome 41 so it will have no imp…
(Google's certificates only last three months and that's not because of this announcement.) The transition that I'm talking about is the transition to SHA-256 overall. If you're in a position where your CA sold you a certificate that they shouldn't have then I feel sorry, but if you're blaming us for that then I think you're pointing in the wrong direction.
What would be the technical challenges facing offering free wildcard certs? Is it just engineering time, or is there something more fundamental? That seems like it would do much more for web security than pushing for higher minimum encryption standards on certs would...
Earlier quoted context omitted.
After reading that blog post from Microsoft, I believe even stronger now that Google is approaching this carelessly. Microsoft announced this almost a year ago and yet the blog post reads that they are giving until January 1st 2017 until they will stop accepting SHA-1 certs. Google announced this today and starting in 22 days they will be showing a Yellow Lock on my certificate just because the cert is set to expire…
Presumably the thinking is that certs shouldn't be issued with a validity more than a year or two. So certs expiring 2017 shouldn't be issued before 2015 or 2016… plenty of time for people to start issuing newer certs with stronger hashing. And if they don't… it's just a small visual warning, for now. Other than not getting this started sooner, it seems fine to me.
The post says that in Chrome 41 (Q1 2015) the https will display in red with a strikethrough, which is more than a small visual warning.
I think it's really crazy that certificates are now declared insecure based on their expiration date. We've deployed several certificates with a three year validity (i.e. valid after 1-Jan-2017), and since our CA could only provide SHA-1, that's what we're using. Now these certificates get marked as insecure. However, if we'd gone for a 2 year validity, we'd be fine until somewhere in 2016. How does this help securit…
So, deprecating a certificate on the basis of the issue date is a decision that makes to force people to start caring of the whole problem at the certain date, but then you would have people getting a 5 year SHA1 the day before the cutoff. Deprecating on the expiration date is the decision that better models the security risks.
Earlier quoted context omitted.
Unfortunately we don't have the technical ability, nor do people have the mental capacity, to cope with multiple URL schemes for different "levels" of security. SHA-1 limits the security for everyone and all uses. And if sites are worried about compat, Google will be doing this transition along with everyone else. That's a good tailwind to ride. If Microsoft's 2016/2017 deadline is reckless, what SHA-1 deprecation da…
Google, CloudFlare and a handful of the technically sophisticated organizations have the ability to return different certificates depending on the connecting browser. Your argument would be far more persuasive if Google were really biting the bullet and dropping support for SHA1 even when an old browser connects. I assume that's not what you're doing, but please correct me if I'm wrong. If you are returning two diffe…
One of the affected sites will be LinkedIn. I think they tried SHA256 once before reverting to SHA1.
Digicert, the CA that signs their cert, is all SHA1, so they'll probably need to change CAs at a minimum.
I think it's really crazy that certificates are now declared insecure based on their expiration date. We've deployed several certificates with a three year validity (i.e. valid after 1-Jan-2017), and since our CA could only provide SHA-1, that's what we're using. Now these certificates get marked as insecure. However, if we'd gone for a 2 year validity, we'd be fine until somewhere in 2016. How does this help securit…
Because an attacker could get a copy of your certificate now, begin looking for a sha1 collision, and ride the Moore law until 2017; at any time they find a collision, they can begin MITM-ing your users. Have a look at the numbers linked in OP for an idea of the cost that is required to collide SHA1; news at 5pm: it's well within NSA wallet, and goes down and down very fast. So, deprecating a certificate on the basis…
I'm concerned that the net effect of this will be to make the Internet less secure. In most cases, webmasters will be forced to make a Faustian choice: live with the scary warning in Chrome for modern users or give up support of browsers running on Windows XP (pre-SP3) and early versions of Android (pre-2.3), since they don't support certificates with a more secure hash than SHA1. We'll likely write a blog post soon…
The situation with Android, vendors, old versions, device abandonment and lack of security patches is terribly disappointing across the ecosystem. It does not have the same excuse of age that Windows XP does. I'm not sure how to remedy that, and I'm not even completely sure why it happened in the first place except for the melting pot of: carriers wanting complete images to test and to remain completely stable (big mistake: most software really needs security patches deployable globally within hours!); SoC vendors with closed-source binary blob drivers, and this being tolerated in the ecosystem (big mistake: this means when it's dead to the vendor it's dead to everyone, because ABI changes); and versions with high minimum memory requirements (which is improving recently, but I feel if you can't go back and run it on the ADP1, and it doesn't run worse than it ever did, you're still not really done with that yet). Projects like CyanogenMod at least help there.
I agree it is shocking how many are still out there, but given the choice between "HTTPS being secure" and "supporting insanely old/insecure software", choosing the latter seems like the kind of choice people will vividly remember when they come to regret it later.