101–110 of 136 posts
... and there it goes, any credibility I would give the author. There's dumbing down the content for a non-technical audience, and there's not understanding.
"SHA1 and other hash algorithms generate a digital fingerprint that in theory is unique for each different file or text input they sign." ... and there it goes, any credibility I would give the author. There's dumbing down the content for a non-technical audience, and there's not understanding.
Earlier quoted context omitted.
If going SHA-2 only requires a request flag, why so long for a transition? Is there some downside (e.g. old clients that don't support it) that holds Google off?
Windows XP SP 2 (SP 3 is fine) and early Android, I believe, are the clients that don't support certs later than SHA-1.
Earlier quoted context omitted.
> I actually suspect that large sites like Facebook, etc will maintain multiple certs at the different levels and dynamically serve the best one up that the client can support. How would you do that? When the TLS connection is established you know nothing about the client except its IP address. All of the interesting information about the browser is transported via the HTTP stream which is tunneled inside the TLS con…
Not true; consider SNI as an example of the server choosing a certificate as part of the handshake, without a cleartext exchange of the hostname. http://en.wikipedia.org/wiki/Server_Name_Indication
Earlier quoted context omitted.
What's weird though is that they have a consortium. They could have all agreed simultaneously to stop issuing SHA1 certs years ago and at no market loss. But they didn't.
No. They've been quite clear about this. CA's are still selling SHA1 certs because customers are asking for them. They're asking for them because they're compatible with more apps/devices and - until now - browsers treated them the same. So why sacrifice compatibility for no improvement. The Chrome team are right to push this along, but I do have some sympathy for the CA's here too. I read the whole discussion and it…
No improvement? How about improvement in security?
Earlier quoted context omitted.
> I actually suspect that large sites like Facebook, etc will maintain multiple certs at the different levels and dynamically serve the best one up that the client can support. How would you do that? When the TLS connection is established you know nothing about the client except its IP address. All of the interesting information about the browser is transported via the HTTP stream which is tunneled inside the TLS con…
Not true; consider SNI as an example of the server choosing a certificate as part of the handshake, without a cleartext exchange of the hostname. http://en.wikipedia.org/wiki/Server_Name_Indication
"SHA1 and other hash algorithms generate a digital fingerprint that in theory is unique for each different file or text input they sign." ... and there it goes, any credibility I would give the author. There's dumbing down the content for a non-technical audience, and there's not understanding.
what's wrong with that statement exactly?
"SHA1 and other hash algorithms generate a digital fingerprint that in theory is unique for each different file or text input they sign." ... and there it goes, any credibility I would give the author. There's dumbing down the content for a non-technical audience, and there's not understanding.
what's wrong with that statement exactly?
1. Hashes don't "sign" things (not directly anyway)
2. Hashes aren't unique in theory or practice (using a 256-bit hash on every 257-bit number will generate 2^256 collisions by the pigeonhole principle).
Earlier quoted context omitted.
That's right, but the root cert is not sent by the server (in my case). More importantly, SHA-1 isn't a problem for root certs, as their signature is not used to verify their integrity.
Then what is the signature for?
Certificate verification stops when you encounter a TA. Some libraries do the wrong thing and check that the terminal cert is self-signed, but that's not actually required (nor recommended). You just check that the previous cert is signed by the TA, which involves checking the previous cert's signature (aka the intermediate) with the trust anchor's key.
That's why the trust anchor's signature is irrelevant.
See RFC 6024 for a discussion of terminology and concepts.
Earlier quoted context omitted.
what's wrong with that statement exactly?
Two things: 1. Hashes don't "sign" things (not directly anyway) 2. Hashes aren't unique in theory or practice (using a 256-bit hash on every 257-bit number will generate 2^256 collisions by the pigeonhole principle).
Suppose every person generates 1 billion files a second * 7 billion people * 1,000 years = ~3x10 ^ 28 call it 10^29. For a collusion among non identical files using a good 256 bit hash you get ~1/(2^256) * (10^29) * (10^29) = ~1/(2^198).
Or 1 chance in ~4 * 10 ^ 59 of finding even one collision.