Interesting article

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Interesting article

Thomas J. Hruska
I know MD5 was broken ages ago but this article expands on the theme -
make your own legitimate-looking root CA:

http://www.crunchgear.com/2008/12/30/md5-collision-creates-rogue-certificate-authority/

--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI, Nuclear Vision, ProtoNova, and Win32 OpenSSL.
http://www.slproweb.com/

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Interesting article

Victor Duchovni
On Tue, Dec 30, 2008 at 06:38:24PM -0700, Thomas J. Hruska wrote:

> I know MD5 was broken ages ago but this article expands on the theme -
> make your own legitimate-looking root CA:

To be precise, not a root CA, but an intermediate CA, from an issuing
CA involved in multiple "unfortunate" practices.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Interesting article

Jason-248
Victor Duchovni wrote:
> On Tue, Dec 30, 2008 at 06:38:24PM -0700, Thomas J. Hruska wrote:
>
>> I know MD5 was broken ages ago but this article expands on the theme -
>> make your own legitimate-looking root CA:
>
> To be precise, not a root CA, but an intermediate CA, from an issuing
> CA involved in multiple "unfortunate" practices.
>

I read this yesterday, and got to thinking about a firefox plugin to generate a warning.  Is it sufficient to check that the cert isn't using MD5 as it's hashing algo?  Or, does every cert between you and the root CA need to be checked?

I guess another way of asking is this, does the rogue intermediate CA have the ability to sign another intermediate CA cert which uses SHA1?

Jason.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Interesting article

Victor Duchovni
On Wed, Dec 31, 2008 at 05:17:00AM -0500, Jason wrote:

> > To be precise, not a root CA, but an intermediate CA, from an issuing
> > CA involved in multiple "unfortunate" practices.
> >
>
> I read this yesterday, and got to thinking about a firefox plugin to
> generate a warning.  Is it sufficient to check that the cert isn't using
> MD5 as it's hashing algo?  Or, does every cert between you and the root
> CA need to be checked?

If you want to check, then every certificate (the leaf and intermediate
CAs) other than the root CA certificate needs to be using SHA-1.

> I guess another way of asking is this, does the rogue intermediate CA
> have the ability to sign another intermediate CA cert which uses SHA1?

Yes. There is no requirement for a CA to use the digest algorithm that
signed the CA's certificate for certs it signs.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Interesting article

Dan_Mitton-2
Don't you have to check the root CA certificate too??



Please respond to [hidden email]
Sent by:        [hidden email]
To:     [hidden email]
cc:      (bcc: Dan Mitton/YD/RWDOE)
Subject:        Re: Interesting article
LSN: Not Relevant - Not Privileged
User Filed as: Excl/AdminMgmt-14-4/QA:N/A

On Wed, Dec 31, 2008 at 05:17:00AM -0500, Jason wrote:

> > To be precise, not a root CA, but an intermediate CA, from an issuing
> > CA involved in multiple "unfortunate" practices.
> >
>
> I read this yesterday, and got to thinking about a firefox plugin to
> generate a warning.  Is it sufficient to check that the cert isn't using
> MD5 as it's hashing algo?  Or, does every cert between you and the root
> CA need to be checked?

If you want to check, then every certificate (the leaf and intermediate
CAs) other than the root CA certificate needs to be using SHA-1.

> I guess another way of asking is this, does the rogue intermediate CA
> have the ability to sign another intermediate CA cert which uses SHA1?

Yes. There is no requirement for a CA to use the digest algorithm that
signed the CA's certificate for certs it signs.

--
                 Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Interesting article

Victor Duchovni
On Wed, Dec 31, 2008 at 09:16:06AM -0800, [hidden email] wrote:

> Don't you have to check the root CA certificate too??

No, in fact one specifically must not, because the root CA cert is
self-signed and there are no chosen-prefix attacks against the self-signed
root CA. Even if you could get a signature collision, root CA certs are
stored locally on each verifier, so their signatures are not important,
an attacker needs to be able to sign content using the same public key,
which requires breaking RSA, not MD5.

Many still current root CAs have MD5 signatures, and these pose no known
risk. See the "Thawte" root CA cert at the bottom of the message.

> > I read this yesterday, and got to thinking about a firefox plugin to
> > generate a warning.  Is it sufficient to check that the cert isn't using
> > MD5 as it's hashing algo?  Or, does every cert between you and the root
> > CA need to be checked?
>
> If you want to check, then every certificate (the leaf and intermediate
> CAs) other than the root CA certificate needs to be using SHA-1.
>
> > I guess another way of asking is this, does the rogue intermediate CA
> > have the ability to sign another intermediate CA cert which uses SHA1?
>
> Yes. There is no requirement for a CA to use the digest algorithm that
> signed the CA's certificate for certs it signs.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=[hidden email]
        Validity
            Not Before: Aug  1 00:00:00 1996 GMT
            Not After : Dec 31 23:59:00 2020 GMT
        Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=[hidden email]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:d2:36:36:6a:8b:d7:c2:5b:9e:da:81:41:62:8f:
                    38:ee:49:04:55:d6:d0:ef:1c:1b:95:16:47:ef:18:
                    48:35:3a:52:f4:2b:6a:06:8f:3b:2f:ea:56:e3:af:
                    86:8d:9e:17:f7:9e:b4:65:75:02:4d:ef:cb:09:a2:
                    21:51:d8:9b:d0:67:d0:ba:0d:92:06:14:73:d4:93:
                    cb:97:2a:00:9c:5c:4e:0c:bc:fa:15:52:fc:f2:44:
                    6e:da:11:4a:6e:08:9f:2f:2d:e3:f9:aa:3a:86:73:
                    b6:46:53:58:c8:89:05:bd:83:11:b8:73:3f:aa:07:
                    8d:f4:42:4d:e7:40:9d:1c:37
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: md5WithRSAEncryption
        26:48:2c:16:c2:58:fa:e8:16:74:0c:aa:aa:5f:54:3f:f2:d7:
        c9:78:60:5e:5e:6e:37:63:22:77:36:7e:b2:17:c4:34:b9:f5:
        08:85:fc:c9:01:38:ff:4d:be:f2:16:42:43:e7:bb:5a:46:fb:
        c1:c6:11:1f:f1:4a:b0:28:46:c9:c3:c4:42:7d:bc:fa:ab:59:
        6e:d5:b7:51:88:11:e3:a4:85:19:6b:82:4c:a4:0c:12:ad:e9:
        a4:ae:3f:f1:c3:49:65:9a:8c:c5:c8:3e:25:b7:94:99:bb:92:
        32:71:07:f0:86:5e:ed:50:27:a6:0d:a6:23:f9:bb:cb:a6:07:
        14:42
-----BEGIN CERTIFICATE-----
MIIDJzCCApCgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBzjELMAkGA1UEBhMCWkEx
FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYD
VQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv
biBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhhd3RlIFByZW1pdW0gU2Vy
dmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNlcnZlckB0aGF3dGUuY29t
MB4XDTk2MDgwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgc4xCzAJBgNVBAYTAlpB
MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEdMBsG
A1UEChMUVGhhd3RlIENvbnN1bHRpbmcgY2MxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xITAfBgNVBAMTGFRoYXd0ZSBQcmVtaXVtIFNl
cnZlciBDQTEoMCYGCSqGSIb3DQEJARYZcHJlbWl1bS1zZXJ2ZXJAdGhhd3RlLmNv
bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0jY2aovXwlue2oFBYo847kkE
VdbQ7xwblRZH7xhINTpS9CtqBo87L+pW46+GjZ4X9560ZXUCTe/LCaIhUdib0GfQ
ug2SBhRz1JPLlyoAnFxODLz6FVL88kRu2hFKbgifLy3j+ao6hnO2RlNYyIkFvYMR
uHM/qgeN9EJN50CdHDcCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG
9w0BAQQFAAOBgQAmSCwWwlj66BZ0DKqqX1Q/8tfJeGBeXm43YyJ3Nn6yF8Q0ufUI
hfzJATj/Tb7yFkJD57taRvvBxhEf8UqwKEbJw8RCfbz6q1lu1bdRiBHjpIUZa4JM
pAwSremkrj/xw0llmozFyD4lt5SZu5IycQfwhl7tUCemDaYj+bvLpgcUQg==
-----END CERTIFICATE-----

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Interesting article

Dan_Mitton-2
What is to prevent someone from forging a root CA and then creating
intermediate certificates signed with SHA1, based on the forged root CA?



Please respond to [hidden email]
Sent by:        [hidden email]
To:     [hidden email]
cc:      (bcc: Dan Mitton/YD/RWDOE)
Subject:        Re: Interesting article
LSN: Not Relevant
User Filed as: Not a Record

On Wed, Dec 31, 2008 at 09:16:06AM -0800, [hidden email] wrote:

> Don't you have to check the root CA certificate too??

No, in fact one specifically must not, because the root CA cert is
self-signed and there are no chosen-prefix attacks against the self-signed
root CA. Even if you could get a signature collision, root CA certs are
stored locally on each verifier, so their signatures are not important,
an attacker needs to be able to sign content using the same public key,
which requires breaking RSA, not MD5.

Many still current root CAs have MD5 signatures, and these pose no known
risk. See the "Thawte" root CA cert at the bottom of the message.

> > I read this yesterday, and got to thinking about a firefox plugin to
> > generate a warning.  Is it sufficient to check that the cert isn't
using
> > MD5 as it's hashing algo?  Or, does every cert between you and the
root

> > CA need to be checked?
>
> If you want to check, then every certificate (the leaf and intermediate
> CAs) other than the root CA certificate needs to be using SHA-1.
>
> > I guess another way of asking is this, does the rogue intermediate CA
> > have the ability to sign another intermediate CA cert which uses SHA1?
>
> Yes. There is no requirement for a CA to use the digest algorithm that
> signed the CA's certificate for certs it signs.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting
cc, OU=Certification Services Division, CN=Thawte Premium Server
CA/emailAddress=[hidden email]
        Validity
            Not Before: Aug  1 00:00:00 1996 GMT
            Not After : Dec 31 23:59:00 2020 GMT
        Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting
cc, OU=Certification Services Division, CN=Thawte Premium Server
CA/emailAddress=[hidden email]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:d2:36:36:6a:8b:d7:c2:5b:9e:da:81:41:62:8f:
                    38:ee:49:04:55:d6:d0:ef:1c:1b:95:16:47:ef:18:
                    48:35:3a:52:f4:2b:6a:06:8f:3b:2f:ea:56:e3:af:
                    86:8d:9e:17:f7:9e:b4:65:75:02:4d:ef:cb:09:a2:
                    21:51:d8:9b:d0:67:d0:ba:0d:92:06:14:73:d4:93:
                    cb:97:2a:00:9c:5c:4e:0c:bc:fa:15:52:fc:f2:44:
                    6e:da:11:4a:6e:08:9f:2f:2d:e3:f9:aa:3a:86:73:
                    b6:46:53:58:c8:89:05:bd:83:11:b8:73:3f:aa:07:
                    8d:f4:42:4d:e7:40:9d:1c:37
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: md5WithRSAEncryption
        26:48:2c:16:c2:58:fa:e8:16:74:0c:aa:aa:5f:54:3f:f2:d7:
        c9:78:60:5e:5e:6e:37:63:22:77:36:7e:b2:17:c4:34:b9:f5:
        08:85:fc:c9:01:38:ff:4d:be:f2:16:42:43:e7:bb:5a:46:fb:
        c1:c6:11:1f:f1:4a:b0:28:46:c9:c3:c4:42:7d:bc:fa:ab:59:
        6e:d5:b7:51:88:11:e3:a4:85:19:6b:82:4c:a4:0c:12:ad:e9:
        a4:ae:3f:f1:c3:49:65:9a:8c:c5:c8:3e:25:b7:94:99:bb:92:
        32:71:07:f0:86:5e:ed:50:27:a6:0d:a6:23:f9:bb:cb:a6:07:
        14:42
-----BEGIN CERTIFICATE-----
MIIDJzCCApCgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBzjELMAkGA1UEBhMCWkEx
FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYD
VQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv
biBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhhd3RlIFByZW1pdW0gU2Vy
dmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNlcnZlckB0aGF3dGUuY29t
MB4XDTk2MDgwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgc4xCzAJBgNVBAYTAlpB
MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEdMBsG
A1UEChMUVGhhd3RlIENvbnN1bHRpbmcgY2MxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xITAfBgNVBAMTGFRoYXd0ZSBQcmVtaXVtIFNl
cnZlciBDQTEoMCYGCSqGSIb3DQEJARYZcHJlbWl1bS1zZXJ2ZXJAdGhhd3RlLmNv
bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0jY2aovXwlue2oFBYo847kkE
VdbQ7xwblRZH7xhINTpS9CtqBo87L+pW46+GjZ4X9560ZXUCTe/LCaIhUdib0GfQ
ug2SBhRz1JPLlyoAnFxODLz6FVL88kRu2hFKbgifLy3j+ao6hnO2RlNYyIkFvYMR
uHM/qgeN9EJN50CdHDcCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG
9w0BAQQFAAOBgQAmSCwWwlj66BZ0DKqqX1Q/8tfJeGBeXm43YyJ3Nn6yF8Q0ufUI
hfzJATj/Tb7yFkJD57taRvvBxhEf8UqwKEbJw8RCfbz6q1lu1bdRiBHjpIUZa4JM
pAwSremkrj/xw0llmozFyD4lt5SZu5IycQfwhl7tUCemDaYj+bvLpgcUQg==
-----END CERTIFICATE-----

--
                 Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Interesting article

Kyle Hamilton
The fact that root certificates are NEVER trusted, under X.509, unless
they're already in the client store (or are added as a specific
security exception).  These are a special class of certificates called
"trust anchors" (technically, the trust anchor is the public key; the
certificate is the thing that holds metadata, including the
subjectKeyIdentifier, which is used in certificates signed by it to
uniquely identify the signing key).

(You get root CAs from places like Microsoft, Mozilla, Apple, Opera,
and your OS distribution vendor.)

The reason why it's very difficult to forge a certificate from a root
CA is due to the mathematics behind asymmetric cryptography.  Please
see a book called "Applied Cryptography 2nd Edition", by Schneier, for
a very good introduction to the concept and a discussion of how
unlikely it is.

-Kyle H

On Fri, Jan 2, 2009 at 7:41 AM,  <[hidden email]> wrote:

> What is to prevent someone from forging a root CA and then creating
> intermediate certificates signed with SHA1, based on the forged root CA?
>
>
>
> Please respond to [hidden email]
> Sent by:        [hidden email]
> To:     [hidden email]
> cc:      (bcc: Dan Mitton/YD/RWDOE)
> Subject:        Re: Interesting article
> LSN: Not Relevant
> User Filed as: Not a Record
>
> On Wed, Dec 31, 2008 at 09:16:06AM -0800, [hidden email] wrote:
>
>> Don't you have to check the root CA certificate too??
>
> No, in fact one specifically must not, because the root CA cert is
> self-signed and there are no chosen-prefix attacks against the self-signed
> root CA. Even if you could get a signature collision, root CA certs are
> stored locally on each verifier, so their signatures are not important,
> an attacker needs to be able to sign content using the same public key,
> which requires breaking RSA, not MD5.
>
> Many still current root CAs have MD5 signatures, and these pose no known
> risk. See the "Thawte" root CA cert at the bottom of the message.
>
>> > I read this yesterday, and got to thinking about a firefox plugin to
>> > generate a warning.  Is it sufficient to check that the cert isn't
> using
>> > MD5 as it's hashing algo?  Or, does every cert between you and the
> root
>> > CA need to be checked?
>>
>> If you want to check, then every certificate (the leaf and intermediate
>> CAs) other than the root CA certificate needs to be using SHA-1.
>>
>> > I guess another way of asking is this, does the rogue intermediate CA
>> > have the ability to sign another intermediate CA cert which uses SHA1?
>>
>> Yes. There is no requirement for a CA to use the digest algorithm that
>> signed the CA's certificate for certs it signs.
>
> Certificate:
>    Data:
>        Version: 3 (0x2)
>        Serial Number: 1 (0x1)
>        Signature Algorithm: md5WithRSAEncryption
>        Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting
> cc, OU=Certification Services Division, CN=Thawte Premium Server
> CA/emailAddress=[hidden email]
>        Validity
>            Not Before: Aug  1 00:00:00 1996 GMT
>            Not After : Dec 31 23:59:00 2020 GMT
>        Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting
> cc, OU=Certification Services Division, CN=Thawte Premium Server
> CA/emailAddress=[hidden email]
>        Subject Public Key Info:
>            Public Key Algorithm: rsaEncryption
>            RSA Public Key: (1024 bit)
>                Modulus (1024 bit):
>                    00:d2:36:36:6a:8b:d7:c2:5b:9e:da:81:41:62:8f:
>                    38:ee:49:04:55:d6:d0:ef:1c:1b:95:16:47:ef:18:
>                    48:35:3a:52:f4:2b:6a:06:8f:3b:2f:ea:56:e3:af:
>                    86:8d:9e:17:f7:9e:b4:65:75:02:4d:ef:cb:09:a2:
>                    21:51:d8:9b:d0:67:d0:ba:0d:92:06:14:73:d4:93:
>                    cb:97:2a:00:9c:5c:4e:0c:bc:fa:15:52:fc:f2:44:
>                    6e:da:11:4a:6e:08:9f:2f:2d:e3:f9:aa:3a:86:73:
>                    b6:46:53:58:c8:89:05:bd:83:11:b8:73:3f:aa:07:
>                    8d:f4:42:4d:e7:40:9d:1c:37
>                Exponent: 65537 (0x10001)
>        X509v3 extensions:
>            X509v3 Basic Constraints: critical
>                CA:TRUE
>    Signature Algorithm: md5WithRSAEncryption
>        26:48:2c:16:c2:58:fa:e8:16:74:0c:aa:aa:5f:54:3f:f2:d7:
>        c9:78:60:5e:5e:6e:37:63:22:77:36:7e:b2:17:c4:34:b9:f5:
>        08:85:fc:c9:01:38:ff:4d:be:f2:16:42:43:e7:bb:5a:46:fb:
>        c1:c6:11:1f:f1:4a:b0:28:46:c9:c3:c4:42:7d:bc:fa:ab:59:
>        6e:d5:b7:51:88:11:e3:a4:85:19:6b:82:4c:a4:0c:12:ad:e9:
>        a4:ae:3f:f1:c3:49:65:9a:8c:c5:c8:3e:25:b7:94:99:bb:92:
>        32:71:07:f0:86:5e:ed:50:27:a6:0d:a6:23:f9:bb:cb:a6:07:
>        14:42
> -----BEGIN CERTIFICATE-----
> MIIDJzCCApCgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBzjELMAkGA1UEBhMCWkEx
> FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYD
> VQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv
> biBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhhd3RlIFByZW1pdW0gU2Vy
> dmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNlcnZlckB0aGF3dGUuY29t
> MB4XDTk2MDgwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgc4xCzAJBgNVBAYTAlpB
> MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEdMBsG
> A1UEChMUVGhhd3RlIENvbnN1bHRpbmcgY2MxKDAmBgNVBAsTH0NlcnRpZmljYXRp
> b24gU2VydmljZXMgRGl2aXNpb24xITAfBgNVBAMTGFRoYXd0ZSBQcmVtaXVtIFNl
> cnZlciBDQTEoMCYGCSqGSIb3DQEJARYZcHJlbWl1bS1zZXJ2ZXJAdGhhd3RlLmNv
> bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0jY2aovXwlue2oFBYo847kkE
> VdbQ7xwblRZH7xhINTpS9CtqBo87L+pW46+GjZ4X9560ZXUCTe/LCaIhUdib0GfQ
> ug2SBhRz1JPLlyoAnFxODLz6FVL88kRu2hFKbgifLy3j+ao6hnO2RlNYyIkFvYMR
> uHM/qgeN9EJN50CdHDcCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG
> 9w0BAQQFAAOBgQAmSCwWwlj66BZ0DKqqX1Q/8tfJeGBeXm43YyJ3Nn6yF8Q0ufUI
> hfzJATj/Tb7yFkJD57taRvvBxhEf8UqwKEbJw8RCfbz6q1lu1bdRiBHjpIUZa4JM
> pAwSremkrj/xw0llmozFyD4lt5SZu5IycQfwhl7tUCemDaYj+bvLpgcUQg==
> -----END CERTIFICATE-----
>
> --
>                 Viktor.
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Interesting article

Victor Duchovni
In reply to this post by Dan_Mitton-2
On Fri, Jan 02, 2009 at 07:41:25AM -0800, [hidden email] wrote:

> What is to prevent someone from forging a root CA and then creating
> intermediate certificates signed with SHA1, based on the forged root CA?

The verifiers (e.g. web browser applications) don't have the "forged"
root CA in their trust database. What does it mean to "forge" a root CA?
What's trusted in a *root* CA is its public key, all the other bits of
information in the certificate are largely irrelevant (used to identify
which root cert to use to validate a given non-root cert it may have
signed).

Please define what you mean when you say "forge" in the case of a root CA.
A root (RSA) CA is a large integer (the public modulus). The concept of
forgery does not really apply to a large integer. The (self) signature
on the root CA cert plays no role in the trust model.

Cloning the self-signature of a root CA onto another certificate requires
one to solve the "second pre-image" problem for MD5. The "second pre-image"
problem for MD5 remains unsolved. We can generate collisions for messages
with chosen prefixes, but we can't choose the MD5 hash value itself, just
the two messages that collide to an MD5 value we can't control.

I think I should stop elaborating this point, if still confused, study
a decent cryptography book...

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Interesting article

Goetz Babin-Ebell
In reply to this post by Dan_Mitton-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[hidden email] wrote:
| What is to prevent someone from forging a root CA and then creating
| intermediate certificates signed with SHA1, based on the forged root CA?

Nothing.
Now his problem is to get the users to include it into their list
of trusted certs.

I'm inclined to say that if they do that, they get what they deserve,
but on second thought that is a little bit harsh:

Unfortunately users only understand SSL/TLS in the way that if the
browser displays that little lock in front of the URL, they are save.
Additionally they also seem to be trained to click on "accept"
if some annoying window pops open when they want to visit a page.

Often it seems they do not realize that they break the whole security
if they do include a CA certificate they did not verify.


Goetz

- --
DMCA: The greed of the few outweighs the freedom of the many
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJXoFv2iGqZUF3qPYRAg2uAJ0ddzlWLD8ItPglbt1J+ktVCOyBiwCfboyw
rX2TiqnJLPw4hPwwOzygHis=
=oaFw
-----END PGP SIGNATURE-----
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Interesting article

Kyle Hamilton
The security model is already broken-by-design because there is only a
single padlock icon in the UI of most browsers -- there is no way to
differentiate the different types of things (not 'technical key
usages', but 'what do I trust the entity I associate the key with
for?') in the UI.

I'm currently researching the failure of the UI in Mozilla Firefox,
since it's much more likely that I'll be able to get them to change
their UI than I would Opera, Microsoft, or Apple.

-Kyle H

On Fri, Jan 2, 2009 at 1:04 PM, Goetz Babin-Ebell <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [hidden email] wrote:
> | What is to prevent someone from forging a root CA and then creating
> | intermediate certificates signed with SHA1, based on the forged root CA?
>
> Nothing.
> Now his problem is to get the users to include it into their list
> of trusted certs.
>
> I'm inclined to say that if they do that, they get what they deserve,
> but on second thought that is a little bit harsh:
>
> Unfortunately users only understand SSL/TLS in the way that if the
> browser displays that little lock in front of the URL, they are save.
> Additionally they also seem to be trained to click on "accept"
> if some annoying window pops open when they want to visit a page.
>
> Often it seems they do not realize that they break the whole security
> if they do include a CA certificate they did not verify.
>
>
> Goetz
>
> - --
> DMCA: The greed of the few outweighs the freedom of the many
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.4-svn0 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFJXoFv2iGqZUF3qPYRAg2uAJ0ddzlWLD8ItPglbt1J+ktVCOyBiwCfboyw
> rX2TiqnJLPw4hPwwOzygHis=
> =oaFw
> -----END PGP SIGNATURE-----
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Interesting article

Thomas J. Hruska
In reply to this post by Kyle Hamilton
Kyle Hamilton wrote:

> The fact that root certificates are NEVER trusted, under X.509, unless
> they're already in the client store (or are added as a specific
> security exception).  These are a special class of certificates called
> "trust anchors" (technically, the trust anchor is the public key; the
> certificate is the thing that holds metadata, including the
> subjectKeyIdentifier, which is used in certificates signed by it to
> uniquely identify the signing key).
>
> (You get root CAs from places like Microsoft, Mozilla, Apple, Opera,
> and your OS distribution vendor.)
>
> The reason why it's very difficult to forge a certificate from a root
> CA is due to the mathematics behind asymmetric cryptography.  Please
> see a book called "Applied Cryptography 2nd Edition", by Schneier, for
> a very good introduction to the concept and a discussion of how
> unlikely it is.
>
> -Kyle H

I'm pretty sure Dan is asking if it is possible to recreate the private
key that generated the public key that is already in the certificate
store (i.e. something you already trust).  Everyone here seems to be
assuming that he meant creating a new root CA.

Issuers re-issue signed keys every year for "security purposes", but if
*I* were some ridiculously-brilliant hacker with unlimited processing
resources and I were targeting a key to break, I would skip that and go
for the Big Enchilada:  A key already in the trusted certificate store
on every user's machine and in every major browser.  With a duplicate
private key (e.g. Verisign's CA _private_ key), I could theoretically
generate any key for any domain I want to intercept/monitor transactions
for.  The additional benefit that most CAs in the certificate store are
good until 2038 instead of a single year only helps further the benefit
of targeting such a key.

Probably impossible.

--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI, Nuclear Vision, ProtoNova, and Win32 OpenSSL.
http://www.slproweb.com/


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Interesting article

Michael S. Zick-4
On Fri January 2 2009, Thomas J. Hruska wrote:

> Kyle Hamilton wrote:
> > The fact that root certificates are NEVER trusted, under X.509, unless
> > they're already in the client store (or are added as a specific
> > security exception).  These are a special class of certificates called
> > "trust anchors" (technically, the trust anchor is the public key; the
> > certificate is the thing that holds metadata, including the
> > subjectKeyIdentifier, which is used in certificates signed by it to
> > uniquely identify the signing key).
> >
> > (You get root CAs from places like Microsoft, Mozilla, Apple, Opera,
> > and your OS distribution vendor.)
> >
> > The reason why it's very difficult to forge a certificate from a root
> > CA is due to the mathematics behind asymmetric cryptography.  Please
> > see a book called "Applied Cryptography 2nd Edition", by Schneier, for
> > a very good introduction to the concept and a discussion of how
> > unlikely it is.
> >
> > -Kyle H
>
> I'm pretty sure Dan is asking if it is possible to recreate the private
> key that generated the public key that is already in the certificate
> store (i.e. something you already trust).  Everyone here seems to be
> assuming that he meant creating a new root CA.
>
> Issuers re-issue signed keys every year for "security purposes", but if
> *I* were some ridiculously-brilliant hacker with unlimited processing
> resources and I were targeting a key to break, I would skip that and go
> for the Big Enchilada:  A key already in the trusted certificate store
> on every user's machine and in every major browser.  With a duplicate
> private key (e.g. Verisign's CA _private_ key), I could theoretically
> generate any key for any domain I want to intercept/monitor transactions
> for.  The additional benefit that most CAs in the certificate store are
> good until 2038 instead of a single year only helps further the benefit
> of targeting such a key.
>
> Probably impossible.
>

Too strong a statement.
Only predicted to take longer than from now until 2038. ;)
"Predicted" with a high degree of confidence, but. . .

Mathematics is not a closed field, it can be extended at any time.
Tomorrow's insight or bit of knowledge may change that degree of
confidence.

On the other hand, you are probably safe to sign on-to your banking
site and make your mortgage payment today. ;)

Mike
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Interesting article

Dan_Mitton-2
In reply to this post by Thomas J. Hruska
Thomas,

Thank you.  You stated my concerns much better then I did.



Please respond to [hidden email]
Sent by:        [hidden email]
To:     [hidden email]
cc:      (bcc: Dan Mitton/YD/RWDOE)
Subject:        Re: Interesting article
LSN: Not Relevant
User Filed as: Not a Record

Kyle Hamilton wrote:

> The fact that root certificates are NEVER trusted, under X.509, unless
> they're already in the client store (or are added as a specific
> security exception).  These are a special class of certificates called
> "trust anchors" (technically, the trust anchor is the public key; the
> certificate is the thing that holds metadata, including the
> subjectKeyIdentifier, which is used in certificates signed by it to
> uniquely identify the signing key).
>
> (You get root CAs from places like Microsoft, Mozilla, Apple, Opera,
> and your OS distribution vendor.)
>
> The reason why it's very difficult to forge a certificate from a root
> CA is due to the mathematics behind asymmetric cryptography.  Please
> see a book called "Applied Cryptography 2nd Edition", by Schneier, for
> a very good introduction to the concept and a discussion of how
> unlikely it is.
>
> -Kyle H

I'm pretty sure Dan is asking if it is possible to recreate the private
key that generated the public key that is already in the certificate
store (i.e. something you already trust).  Everyone here seems to be
assuming that he meant creating a new root CA.

Issuers re-issue signed keys every year for "security purposes", but if
*I* were some ridiculously-brilliant hacker with unlimited processing
resources and I were targeting a key to break, I would skip that and go
for the Big Enchilada:  A key already in the trusted certificate store
on every user's machine and in every major browser.  With a duplicate
private key (e.g. Verisign's CA _private_ key), I could theoretically
generate any key for any domain I want to intercept/monitor transactions
for.  The additional benefit that most CAs in the certificate store are
good until 2038 instead of a single year only helps further the benefit
of targeting such a key.

Probably impossible.

--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI, Nuclear Vision, ProtoNova, and Win32 OpenSSL.
http://www.slproweb.com/


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]