

Google.com is still SHA-1 but they green-light their domains - pmccarren
https://tls.so/results/saved.googlecom.1429596106.6f228b1cd37213931aef2193311d990a.html

======
geofft
The certificate is expiring in less than three months. Chrome has always been
clear that they don't care about SHA-1 certs that are expiring within 2015.
They just want to make sure that when you renew those certs, you renew as
SHA-256.

[http://googleonlinesecurity.blogspot.com/2014/09/gradually-s...](http://googleonlinesecurity.blogspot.com/2014/09/gradually-
sunsetting-sha-1.html)

"Sites with end-entity certificates that expire between 1 January 2016 and 31
December 2016 (inclusive), and which include a SHA-1-based signature as part
of the certificate chain, will be treated as 'secure, but with minor errors'
[i.e., the lock-with-yellow-triangle you also get for mixed content].

"Sites with end-entity certificates that expire on or after 1 January 2017,
and which include a SHA-1-based signature as part of the certificate chain,
will be treated as 'affirmatively insecure'. Subresources from such domain
will be treated as 'active mixed content'."

~~~
Osiris
This just hit me. I was doing some work on my side-business site and noticed a
big red error for the SSL cert. Luckily the process to reissue a new cert was
pretty straight forward and I gotten taken care of the same day.

My SSL provider (namecheap) did send me one email at some point, but I'm sure
I glossed over it because I didn't realize this change was coming.

------
thesimon
Their certs expire before the deadline (only valid for 3 months) so they show
up as green.

They seem to get new certs every three months.

~~~
ygra
How useful is it to get new certs that often? I always had the impression that
certs live only a certain time so that revocation lists can be pruned and
don't grow unbounded over time, or is there anything else to it?

~~~
geofft
That's certainly part of it, but at some point there's a qualitative shift: if
you make certificate lifetimes short enough, you don't need to bother with
revocation lists at all. Since CRLs are unwieldy no matter how you do them,
standard practice for revocation is OCSP, preferably through OCSP stapling,
where you carry a signed response from the CA (valid for about a day) saying
that your certificate hasn't been revoked. Effectively this is just a more
complicated way of getting a new certificate about every day.

The other part is that, if something about a cert turns out to have been a bad
idea, it's much better to only have to wait a few days or even months than to
wait a few years. "Something" could be the algorithm (precisely why Chrome is
yelling at SHA-1 certs that will still be valid in 2017, even though there's
no attack as of right today). It could also be certification practices: if the
community decides that, say, certificates without the `subjectAltName`
extension need to be deprecated because the CN field is underspecified,
nobody's going to want to do revocations for that. So you are stuck waiting
until all current certs expire and get renewed to follow current best
practices.

------
dgomez1092
I noticed that they use a 3 tier system. But even SHA-1 encryption, I wanted
to talk about how it compares to the use of RC4 on AES. I am still learning
about the effectual uses of encryption but it would seem to me that being able
to use modulo as you swap indeces throughout the hash would enable more coerce
authentication if not for the sole reason that it would be difficult to find
out the derivative of both of the numbers that gave modulo. VS AES whose
algorithm uses a reverse mapping of the hash in order to equate the distance
from left to right between the indeces.It is said that RC$ is less secure as a
method because of it is more prone to WEP attacks due to its inability to
factorialize an instance of teh hash suring the scheduling phase, while it
only allows for a 64 bit size whereas AES is more sutiable for 256 bit. It's
adavtnage lies in large network systems but would be suitable for API
distributions. In effect its PRG would be effective in taking a modulo
variable being parsed as K[] progresses through the list in a function that
combines it along wth the inverse natural e in to create an limit as
protection from FMS attacks even at a byte level. Thanks for letting me
comment and learn.

------
alanfranzoni
Beyond the expiry fact, I think google does pinning for their certs. If you
pin your certs you don't really care a lot whether the ca is compromised, and
here it's just the ca that's got sha1 signing, not the actual cert which is
sha2.

~~~
riking
No, the *.google.com cert has SHA-1. It's just that it expires before 2016, as
they get issued for 3 months.

~~~
alanfranzoni
You're right. I must have imagined the SHA-256 part.

