Negative RSA moduli from X509 parsing #56
Comments
|
strange (I can reproduce this with ocaml-x509). so the ASN.1 encoding of the modulus of the public exponent is (in hex): According to layman ASN.1 section 5.7, Did you create the certificate? If so, with which tool? (I'm not the expert here, @pqwy certainly knows more) NOTE: updated to clear up my length confusion |
|
Hmm correct (even though the integer starts at AC and not 80 which is still part of the data size). I did not generated the certificate, just got it from the zmap data set |
|
As Nathan hint at, https://en.wikipedia.org/wiki/X.690#Length_Octets tend to indicate that |
|
sorry for my length confusion, I updated my comment to reflect reality. what to do: there are tools which produce wrong certificates. these certificates are in the wild. I believe we've to provide a non-negative integer decoder in asn1-combinators and use this for public keys. |
|
That would be great, ty ! That's what openssl seems to do. It adds a leading 0 byte |
|
The central question in my mind is how widespread is this.
In general, no. I am very reluctant to add warts to support other people's old bugs. These certificates are badly encoded, making them invalid. They should be replaced, not used, and definitely not worked around in newly written software. Well, unless this is really common practice. We do have a precedent of bending the standard here. But that is not a work-around, in that case everyone other than the standard seems to agree on the encoding. As a side-note, accepting this would violate the core DER property of uniqueness of representation. Thus we immediately lose the invariant that you can encode a certificate and arrive at the same byte sequence your parsed it from. This is not something to lose lightly. The fact that OpenSSL is always willing to add warts is one of the reasons OpenSSL is what it is, plus, they have a very relaxed interpretation of certificate usage flags and are generally eager to accept any byte stream that someone claims to contain a certificate. To resolve this dilemma I downloaded Zenmap's sample of HTTPS certificates from two days ago. Of those, we parse 508723 and reject 4382 (which is most probably a bug I will now look into). I was wondering how many certificates had negative moduli under the current decoding? Three. Namely: IMHO this change is not justified.
Which file is it in? It's an old self-signed EDIT: |
|
Speaking of newly written software:
|
|
Some more results from digging around the Sonar set:
Unknown algorithms are:
That last one, -- Just wanted to share. |
|
thanks @pqwy, this is a great breakdown. and I agree that the number of certificates with negative moduli is so small that we shouldn't implement workarounds for them. |
|
I took my data set from https://scans.io/series/443-https-tls-full_ipv4 (the 2015-04-02 one). |
|
closing since @pqwy and myself decided that we don't want to implement ugly hacks for broken software (which affects <2% of people) |
When parsing some certificates using X509 I get a RSA pubkey with a negative modulus, but when parsing the same certificate with openssl I get a proper modulus.
I have the same issue whether I'm using X509.Encoding.parse on the DER encoded certificate or X509.Encoding.Pem.Cert.of_pem_cstruct1 on the PEM encoded certificate.
I had different negative moduli even though I can get the same from different certificates with totaly different keys.
For instance when parsing the following certificate :
-----BEGIN CERTIFICATE-----
MIICgjCCAeugAwIBAgIBADANBgkqhkiG9w0BAQUFADB8MSMwIQYDVQQDDBpNYXRy
aXhTU0wgU2FtcGxlIFNlcnZlciBDQTELMAkGA1UEBgwCVVMxCzAJBgNVBAgMAldB
MREwDwYDVQQHDAhCZWxsZXZ1ZTEZMBcGA1UECgwQUGVlcnNlYyBOZXR3b3JrczEN
MAsGA1UECwwEVGVzdDAeFw0wNjAzMTMwODEzMzRaFw0wNzAzMTMwODEzMzRaMH4x
JTAjBgNVBAMMHE1hdHJpeFNTTCBTYW1wbGUgU2VydmVyIENlcnQxCzAJBgNVBAYM
AlVTMQswCQYDVQQIDAJXQTERMA8GA1UEBwwIQmVsbGV2dWUxGTAXBgNVBAoMEFBl
ZXJTZWMgTmV0d29ya3MxDTALBgNVBAsMBFRlc3QwgZ4wDQYJKoZIhvcNAQEBBQAD
gYwAMIGIAoGArLJFx36VVxymSgNnepNJfNQ2Wh6RUoe3n6YakhtPWCXHRvGwNBr6
lOqt5bZkcsqM2FkUYMAdIV3DTvMXAVOUf9q0Ys27oIDny/0h2D8vVehjIScYrMrm
xPULuVuovFW4q+VMu+5vMp7U29j0zOHfn/xe687X7DjyaMd19eCcHiECAwEAAaMT
MBEwDwYDVR0TAQEBBAUwAwEBADANBgkqhkiG9w0BAQUFAAOBgQBX6R0aLW/agkug
2zl7kOxssCzi2l55Co6oGno+9t4Xk2IMVpIU/gas8RwnQRjFhw1M02yWobxYEh32
WRJdomY7VNB3m73VhMX909fP+m/d4shJNwB35oZn8JZPjmk9NB/ZGvxK6Zk0WttV
F/KVvu5//R80bStnBA4cAhP7FyUugg==
-----END CERTIFICATE-----
I get the following modulus using openssl :
121271520231624918542907720666513451111373723194411941835436037579884871354630882774466980950040637618229635985716165799223521502108721938227405738374601994957375171061467139291846177087270146140905134669029738067590090603243622428305533878351496216340646248930115097707562917176741486307355852155190932938273and the following one using X509 :
-58497793254606672230022798412389022250423974699818715437994043577847804450870080358241496372366898402890477894155227558435268266705694684265441692264872129420392722363398345984456042513975947978547948283055267701248060079098840453168379232189331020822704261754471200532384328761738229997479504174433291198943Do you have any idea where this might come from ?
The text was updated successfully, but these errors were encountered: