
SHA-256 Certificates Are Coming - sctb
https://www.imperialviolet.org/2014/05/14/sha256.html
======
otterley
It's already here in fact. About a month ago, Comodo stopped issuing
certificates from its old SHA-1 intermediaries. When we had ours reissued
after Heartbleed, it was signed by a SHA-256 intermediate certificate.

We found out the impact of this the hard way -- not only with Windows older
than XP Service Pack 3, but also with embedded systems and devices built with
OpenSSL older than 0.9.8o.

~~~
kijin
What type of certificate did you get, and what was the intermediate
certificate named?

I'm asking because I recently bought a Comodo PositiveSSL certificate, and it
was still signed with SHA-1. The intermediate certificate was also signed with
SHA-1 (the same one that they've been using for quite a while already). I
guess they reserve SHA-256 to more expensive products for now?

~~~
otterley
Ours is Organization Validated - it's possible that they're still using SHA-1
intermediates for Domain Validated certificates.

------
IvyMike
> But there are a lot of people using Windows XP prior to Service Pack 3, and
> they will have problems.

I think a lot of times people on HN and related sites are a little callous to
the needs of users stuck on old platforms. But in this case even I'm like
"screw those people". Is there any common legitimate reason to be on XP but
not be able to go to SP3?

~~~
nuxi7
With the deah of XP, the whole "why would you still be running X?" thing is a
very popular attitude lately. I myself enjoy poking fun of my friend who works
somewhere that just recently upgraded from MSIE 6 on XP to MSIE 7 on XP. I
have another friend who works somewhere that decided the fix was to install
Firefox on everyone's XP machines. (Oh the irony of being somewhere that
didn't allow firefox for "security reasons" having to install Firefox for
security reasons.)

The truth is that Linux is actually mature enough now that is is facing many
of the same issues. The inevitable competing interests of a stable base to
support on one hand and the need for the latest features or hardware support
on the other are very real even for Linux.

Need to run proprietary software on Linux? The supported distro is often still
RHEL5. If you are lucky its RHEL6, but that often does not include RHEL6.5.
The same goes for hardware driver support. I use something regularly that only
supports Debian, but the version it supports was already known as Old-Stable
at the time of release and its now Old-Old-Stable. (And its only through luck
that its not Debian Old-Old-Old-Stable like it was originally going to be) Not
every commercial linux vendor falls into this habit, but enough do that its a
very real problem. Often you have conflicting requirements from different
vendors, or even for different applications from a single vendor.

Think this is limited to proprietary software... Which version of python are
you running? If you answer python3, do you also have python2 installed as
well? Thats what I thought :) (Inevitably the 5 people who have succesfully
and fully migrated to python3 will reply just to prove me wrong, but those 5
are the rare exceptions.)

~~~
deckiedan
I was bitten recently when I found that CentOS 6.5+ actually still has Python
2.6 !!!! as the default python.

I thought I could get away with a few python2.7isms, but apparently not :-(

~~~
nuxi7
[root@vm-centos5 ~]# python

Python 2.4.3 (#1, Jan 9 2013, 06:47:03)

[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux2

Type "help", "copyright", "credits" or "license" for more information.

------
smussmann
> There are lots of properties by which one can evaluate a hash function, but
> the most important are preimage resistance (if I give you a hash, can you
> find an input with that hash value?), second preimage resistance (if I give
> you a message, can you find another that hashes to the same value?) and
> collision resistance (can you find two messages with the same hash?). Of
> those, the third appears to be much harder to meet than the first two, based
> on historical results against hash functions.

To my (crypto noob) eyes, it seems like second preimage resistance is just a
specific case of collision resistance. In both, we're trying to find two
messages that have the same hash value, but with collision resistance, we can
choose the first one arbitrarily. The last sentence, saying that collision
resistance is a higher barrier than second preimage resistance, thus doesn't
seem to make much sense to me. What am I missing?

~~~
agl
Collision resistance is harder to meet in the same way that "stronger" results
are harder to prove. That is, I think you're correct and that my wording was
just confusing, sorry!

Historically, many hash functions have been broken by collisions, but even
very "weak" hash functions (i.e. MD5) still have full design strength for
preimage and second-preimage resistance (as far as I know).

~~~
dfc
Out of curiosity is there a reason why cert-test.sandbox.g.c resolves to so
many IPs compared to www.g.c?

    
    
      dfc@ronin:~$ host cert-test.sandbox.google.com |grep address |wc
           16      64     894
      dfc@ronin:~$ host www.google.com |grep address |wc
            6      25     262
    

I wanted to see how the various vendor ssl tests would handle sha256.
Everything i tested had no problem, but they all took a little longer than
usual because of the number of DNS results.

PS Not that it would matter but unlike other google hosts the cert-test does
not have any IPv6 records.

~~~
agl
I don't think the load balancing is setup as tightly as www.google.com. It
doesn't get much traffic after all.

------
myhf
This article talks about strength in terms of number of operations, but
wouldn't it make more sense to think in terms of amount of energy? SHA-256 can
be very cost-effective to mount a long-term collision attack against, given
the existence of SHA-256 ASICs.

~~~
pushedx
I've mounted a growing suspicion that Bitcoin was developed to create a need
for SHA-256 ASICs. Well, here they are, and it's much easier to brute-force a
SHA-256 hash collision than it was 5 years ago. In fact you can compute
billions of hashes per second for less than the cost of a PC.

~~~
gwillen
As an owner of a Bitcoin ASIC, I don't _think_ they're usable for general
SHA-256. I think they're all specialized for SHA-256(SHA-256(X)), where X must
be a packet in a bitcoin-specific format.

~~~
cantfindmypass
Correct, they cannot compute SHA256() or SHA256(SHA256()) of arbitrary data.

~~~
pushedx
Well, I stand corrected. Especially in light of the analyses provided in
sibling comments.

------
kijin
Other than Windows XP pre-SP3, does anyone have a list of operating systems
and/or devices that will have a problem with SHA-256 certificates?

I tried loading [https://cert-test.sandbox.google.com/](https://cert-
test.sandbox.google.com/) in Android 2.3, the earliest version of Android that
I care about. This is an OS that has given me much pain because it doesn't
support SNI. So I was pleasantly surprised to find that it recognizes the
SHA-256 certificate just fine.

What about OSX and iOS?

------
mrsaint
CAs are already preparing as well.

GlobalSign for example: [https://www.globalsign.eu/ssl-information-
center/transitioni...](https://www.globalsign.eu/ssl-information-
center/transitioning-to-sha-256.html)

And generally: [https://casecurity.org/2014/01/30/why-we-need-to-move-to-
sha...](https://casecurity.org/2014/01/30/why-we-need-to-move-to-sha-2/)

------
apaprocki
Re: XP, Maybe I'm just not aware and others just know this -- but it seems
like XP numbers in GA are screwy. The vast majority of XP users report the
latest versions of FF/Chrome, which doesn't seem correct. Are there known
proxy devices or something similar that cause GA to mis-report OS?

