Rejecting SHA-1 certificates

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Rejecting SHA-1 certificates

Niklas Keller
Morning,

I'm currently trying to reject certificate chains which rely on MD5 and SHA-1 for signatures. I found SSL_get0_verified_chain which could be used to walk the chain and reject if there's any MD5 / SHA-1 certificate in there, except for the last one, which is trusted because of the public key instead of based on the signature, so a weak signature algorithm doesn't have any impact there.

Unfortunately, SSL_get0_verified_chain is only available in OpenSSL 1.1, but not in OpenSSL 1.0.1 or 1.0.2, which both have to be supported. With OpenSSL 1.1, we could also just use "auth_level" and be done.

What's the best way / a working way to reject weak signature schemes in OpenSSL 1.0.{1,2}?

Regards, Niklas


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rejecting SHA-1 certificates

Viktor Dukhovni

> On Jul 10, 2017, at 3:45 AM, Niklas Keller <[hidden email]> wrote:
>
>
> What's the best way / a working way to reject weak signature schemes in OpenSSL 1.0.{1,2}?

Most CAs have stopped issuing SHA-1 certificates.  Any old ones will expire over the
next year or two.  While Google has demonstrated a SHA-1 collision, that proof of
concept is far from a practical attack.

The simplest solution is to let the CAs solve the problem as SHA-1 certificates fade
out of the picture.  You can if you wish leave out from the set of trusted roots any
CAs that have not yet stopped issuing SHA-1 certificates.

You can of course implement a verify callback that inspects each certificate in the
chain, and triggers an error when its signature is SHA-1 and it is not the last one
in the chain.  This requires keeping some state attached to the X509 store context,
and I don't think is worth the effort.

See code involving "TLScontext_index" in:

https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L318
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L942
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_verify.c#L163

With such a context, you can keep track of the maximum depth seen by the callback,
and reject SHA-1 at lower depths.  I do not recommend doing this.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rejecting SHA-1 certificates

Niklas Keller
> On Jul 10, 2017, at 3:45 AM, Niklas Keller <[hidden email]> wrote:
>
>
> What's the best way / a working way to reject weak signature schemes in OpenSSL 1.0.{1,2}?

Most CAs have stopped issuing SHA-1 certificates.  Any old ones will expire over the
next year or two.  While Google has demonstrated a SHA-1 collision, that proof of
concept is far from a practical attack.

Actually they should already be expired, all major browsers will reject them already, even Edge.
 
The simplest solution is to let the CAs solve the problem as SHA-1 certificates fade
out of the picture.  You can if you wish leave out from the set of trusted roots any
CAs that have not yet stopped issuing SHA-1 certificates.

CAs can't solve the problem that we accept certificates with weak signatures.
 
You can of course implement a verify callback that inspects each certificate in the
chain, and triggers an error when its signature is SHA-1 and it is not the last one
in the chain.  This requires keeping some state attached to the X509 store context,
and I don't think is worth the effort.

It's very well worth the effort, otherwise there's a security issue, because certificates can be forged.

Regards, Niklas
 
See code involving "TLScontext_index" in:

https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L318
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L942
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_verify.c#L163

With such a context, you can keep track of the maximum depth seen by the callback,
and reject SHA-1 at lower depths.  I do not recommend doing this.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rejecting SHA-1 certificates

Viktor Dukhovni

> On Jul 10, 2017, at 1:12 PM, Niklas Keller <[hidden email]> wrote:
>
> It's very well worth the effort, otherwise there's a security issue, because certificates can be forged.

Collision attacks don't directly lead to certificate forgery.  There are
no known 2nd-preimage attacks on SHA-1.

The previous MD5 attack required CAs to issue certificates with predictable
content (serial numbers and the like) so that the requested certificate
collides with a rogue certificate with basicConstraints CA:true.  Unpredictable
serial numbers defeat that attack.

If trusted CAs are no longer issuing SHA-1 certificates, then soon you won't need
to detect SHA-1 certificates in trusted chains, as there won't be any such
certificates issued by trusted CAs.

Anyway, if you must, you can inspect the chain as it is being verified via the
verify callback, keep track of the maximum depth (the final set of callbacks
when all goes well start with the topmost CA certificate and goes down towards
the leaf) and reject SHA-1 at depths below any depth seen before.

That's a bunch of code, to address an issue that is solving itself naturally
through attrition.

--
--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rejecting SHA-1 certificates

Michael Wojcik
In reply to this post by Niklas Keller
> From: openssl-users [mailto:[hidden email]] On Behalf Of Niklas Keller
> Sent: Monday, July 10, 2017 11:12
> To: [hidden email]
> Subject: Re: [openssl-users] Rejecting SHA-1 certificates


> It's very well worth the effort, otherwise there's a security issue, because certificates can be forged.

Care to demonstrate that?

The SHAttered attack demonstrated an SHA1 collision using 1) an enormous amount of resources and 2) a file format with plenty of scope for manipulating the preimages. I'm not aware of any public demonstration showing anything close to a practical way of forging an X.509 certificate with an SHA1-based signature. Certificates have far less scope for manipulating the preimage.

It's always been possible to forge certificates. Generally that's been done by stealing the signing key from  a poorly-secured CA. The new marginal feasibility of producing SHA1 collisions does not significantly increase the forgery risk for X.509 certificates at present, since it's probably still too difficult - perhaps not even possible for any useful forgery (if the forged certificate had to carry a suspect amount of unexpected data, for example) - and certainly far too expensive to justify the vast majority of potential attacks.

A security vulnerability is meaningless outside the context of a threat model. Forging certificates with SHA1-based signatures is a very minor branch of the attack tree for nearly all certificate holders. CAs and browser vendors are getting rid of SHA1-based signatures now because the cost of being proactive is very small, and attacks only get better. That doesn't mean immediately screening out all SHA1-based certificates is justified under sensible threat models.

What's your threat model, and how does it justify this effort?

Michael Wojcik
Distinguished Engineer, Micro Focus


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rejecting SHA-1 certificates

Niklas Keller
2017-07-10 19:30 GMT+02:00 Michael Wojcik <[hidden email]>:
> From: openssl-users [mailto:[hidden email]] On Behalf Of Niklas Keller
> Sent: Monday, July 10, 2017 11:12
> To: [hidden email]
> Subject: Re: [openssl-users] Rejecting SHA-1 certificates


> It's very well worth the effort, otherwise there's a security issue, because certificates can be forged.

Care to demonstrate that?

I'm not sure how feasible that is for either SHA1 or MD5.
 
The SHAttered attack demonstrated an SHA1 collision using 1) an enormous amount of resources and 2) a file format with plenty of scope for manipulating the preimages. I'm not aware of any public demonstration showing anything close to a practical way of forging an X.509 certificate with an SHA1-based signature. Certificates have far less scope for manipulating the preimage.

It's always been possible to forge certificates. Generally that's been done by stealing the signing key from  a poorly-secured CA. The new marginal feasibility of producing SHA1 collisions does not significantly increase the forgery risk for X.509 certificates at present, since it's probably still too difficult - perhaps not even possible for any useful forgery (if the forged certificate had to carry a suspect amount of unexpected data, for example) - and certainly far too expensive to justify the vast majority of potential attacks.

Probably true, yes.
 
A security vulnerability is meaningless outside the context of a threat model. Forging certificates with SHA1-based signatures is a very minor branch of the attack tree for nearly all certificate holders. CAs and browser vendors are getting rid of SHA1-based signatures now because the cost of being proactive is very small, and attacks only get better. That doesn't mean immediately screening out all SHA1-based certificates is justified under sensible threat models.

What's your threat model, and how does it justify this effort?

The same as for browsers I guess. Could you explain why browsers and Java disable SHA1, but it's not worth for me doing so?

Regards, Niklas

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rejecting SHA-1 certificates

Michael Sierchio
In reply to this post by Viktor Dukhovni

On Mon, Jul 10, 2017 at 10:22 AM, Viktor Dukhovni <[hidden email]> wrote:

> On Jul 10, 2017, at 1:12 PM, Niklas Keller <[hidden email]> wrote:
>
> It's very well worth the effort, otherwise there's a security issue, because certificates can be forged.

Collision attacks don't directly lead to certificate forgery.  There are
no known 2nd-preimage attacks on SHA-1.

I'm pretty sure, but are you saying you would rather wait for a demonstration of the weakness being turned into a practical attack?

Second pre-image attacks against reduced SHA-1 have been demonstrated. It's only a matter of time before second pre-image resistance for full SHA-1 is dead and buried.

--
"Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred."

- The Mahābhārata

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rejecting SHA-1 certificates

Viktor Dukhovni
On Mon, Jul 10, 2017 at 08:19:11PM +0200, Niklas Keller wrote:

> > What's your threat model, and how does it justify this effort?
>
> The same as for browsers I guess. Could you explain why browsers and Java
> disable SHA1, but it's not worth for me doing so?

The browsers and Java do this because they can (they control the
underlying libraries) and in order to prod the CAs into action,
and to force server operators to move to SHA2.

There is no immediate threat, but the goal is to move the ecosystem
away from SHA-1.  Now that they've done that, you don't need to
refuse SHA-1 in every piece of legacy software (e.g. OpenSSL 1.0.x).
Your contribution to purging SHA-1 from the public Internet would be
negligible.


On Mon, Jul 10, 2017 at 12:07:42PM -0700, Michael Sierchio wrote:

> > Collision attacks don't directly lead to certificate forgery.  There are
> > no known 2nd-preimage attacks on SHA-1.
>
> I'm pretty sure, but are you saying you would rather wait for a
> demonstration of the weakness being turned into a practical attack?

Making your code more complex is a far higher risk than a practical
certificate forgery based on a collision attack on SHA-1.

> Second pre-image attacks against reduced SHA-1 have been demonstrated. It's
> only a matter of time before second pre-image resistance for full SHA-1 is
> dead and buried.

We don't even have 2nd-preimage attacks on MD5 yet.  I'm not holding my
breath for 2nd-preimage attacks on full SHA-1.

Anyway, you can, if you wish, implement a verification callback
that makes the appropriate checks for OpenSSL 1.0.x, but my advice
is to just let the CAs get rid of SHA-1 under pressure from the
browsers, Java, ...

In OpenSSL 1.2.0 (not sure about 1.1.1) we can designate SHA-1 as too
weak for security level 1, and at that time, OpenSSL applications
linked with OpenSSL will by default refuse to validate certificate
signatures based on SHA-1.

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rejecting SHA-1 certificates

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Viktor Dukhovni
> Sent: Monday, July 10, 2017 13:24
> To: [hidden email]
> Subject: Re: [openssl-users] Rejecting SHA-1 certificates
>
> On Mon, Jul 10, 2017 at 08:19:11PM +0200, Niklas Keller wrote:
>
> > > What's your threat model, and how does it justify this effort?
> >
> > The same as for browsers I guess. Could you explain why browsers and
> Java
> > disable SHA1, but it's not worth for me doing so?
>
> The browsers and Java do this because they can (they control the
> underlying libraries) and in order to prod the CAs into action,
> and to force server operators to move to SHA2.

That, and PR. Google has Chrome deprecate SHA-1, so they can wave the security flag. Then everyone else has to follow suit to prove they're equally concerned with security.

Security is always about economics. Deprecating SHA-1 is cheap for the major browsers; there's a small development cost and some irritation to users, but if all the major browsers do it, then the latter becomes an externality - it's not going to cost the browsers any market share. And while it doesn't have a lot of value, as Viktor pointed out, it does prod CAs and server owners to update now, before there's any real threat. So there's some return - enough to justify their investment.

For the vast majority of OpenSSL-based applications, the higher cost is not justified by the lower return. We've already noted why the cost is higher. The return is lower because most OpenSSL-based applications are much less prominent than browsers, so fewer people will notice (thus there's less PR and industry-prodding benefit) and less risk of some wildly well-resourced attacker trying to forge a certificate (assuming that's even feasible, given the constraints of the format).

More generally, making security decisions without understanding your threat model and at least estimating the cost/benefit ratio is a Bad Thing. It's stabbing in the dark. And it's critical to include the opportunity cost - could those resources be put to better use, such as finding and fixing more realistic vulnerabilities?

Michael Wojcik
Distinguished Engineer, Micro Focus

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rejecting SHA-1 certificates

OpenSSL - User mailing list
In reply to this post by Niklas Keller
> It's very well worth the effort, otherwise there's a security issue, because certificates can be forged.

No they cannot.

What *has* been done is a document was created with "weak spots" and another document was created that  changed those weak spots, but the digest was the same.

This is a long long long way from creating two certificates with the same digest (and therefore the same signature).

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rejecting SHA-1 certificates

Jakob Bohm-7
In reply to this post by Viktor Dukhovni
On 10/07/2017 18:52, Viktor Dukhovni wrote:

>> On Jul 10, 2017, at 3:45 AM, Niklas Keller <[hidden email]> wrote:
>>
>>
>> What's the best way / a working way to reject weak signature schemes in OpenSSL 1.0.{1,2}?
> Most CAs have stopped issuing SHA-1 certificates.  Any old ones will expire over the
> next year or two.  While Google has demonstrated a SHA-1 collision, that proof of
> concept is far from a practical attack.
>
> The simplest solution is to let the CAs solve the problem as SHA-1 certificates fade
> out of the picture.  You can if you wish leave out from the set of trusted roots any
> CAs that have not yet stopped issuing SHA-1 certificates.
>
> You can of course implement a verify callback that inspects each certificate in the
> chain, and triggers an error when its signature is SHA-1 and it is not the last one
> in the chain.  This requires keeping some state attached to the X509 store context,
> and I don't think is worth the effort.
>
> See code involving "TLScontext_index" in:
>
> https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L318
> https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L942
> https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_verify.c#L163
>
> With such a context, you can keep track of the maximum depth seen by the callback,
> and reject SHA-1 at lower depths.  I do not recommend doing this.
>
I don't think a state is really needed for this, if the callback
simply checks if the certificate is in the loaded trust collection,
and/or if it is self-signed (depending on the application's chosen
root CA trust model).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rejecting SHA-1 certificates

Viktor Dukhovni
On Wed, Jul 12, 2017 at 02:02:31AM +0200, Jakob Bohm wrote:

> I don't think a state is really needed for this, if the callback
> simply checks if the certificate is in the loaded trust collection,
> and/or if it is self-signed (depending on the application's chosen
> root CA trust model).

Yes, though that too is complicated, e.g. DANE-TA(2) validation
often produces chains where none of the certs are in the local
store or self-signed.  And checking the trust stores for an
exact match takes some care...

The stateful approach is in some ways more elementary.

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rejecting SHA-1 certificates

Jakob Bohm-7
On 12/07/2017 07:23, Viktor Dukhovni wrote:

> On Wed, Jul 12, 2017 at 02:02:31AM +0200, Jakob Bohm wrote:
>
>> I don't think a state is really needed for this, if the callback
>> simply checks if the certificate is in the loaded trust collection,
>> and/or if it is self-signed (depending on the application's chosen
>> root CA trust model).
> Yes, though that too is complicated, e.g. DANE-TA(2) validation
> often produces chains where none of the certs are in the local
> store or self-signed.  And checking the trust stores for an
> exact match takes some care...
>
> The stateful approach is in some ways more elementary.
>
Well, I guess that for DANE-TA, it would be OK to just insist
on no SHA-1 in the chain at all.

Given the limited abilities of (at least previous) versions
of the OpenSSL chain validation/building code, just checking
for self-signed would probably be good enough for now.

Hopefully any future improved OpenSSL code (that checks all
attributes currently ignored) would also provide a new
callback prototype that receives extra information about
the (OpenSSL internal) situation in which it was called, such
as "called from TLS server checking received client cert, this
is the end/middle/trusted cert in the candidate chain, and here
is the SSL_CTX* for that connection".  And with more sensibly
named/defined callback return values too (such as "reject this
cert, try another chain", "reject this cert, and all chains
containing it", "abort the connection, never mind the certs",
"accept this cert, despite the list of failed standard checks
reported to the callback (perhaps shown to the user in a prompt)",
"accept this cert and don't check the chain above it").


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rejecting SHA-1 certificates

Verhelst Wouter (Consultant)
In reply to this post by OpenSSL - User mailing list
On 11-07-17 23:44, Salz, Rich via openssl-users wrote:
>> It's very well worth the effort, otherwise there's a security issue, because certificates can be forged.
>
> No they cannot.
>
> What *has* been done is a document was created with "weak spots" and another document was created that  changed those weak spots, but the digest was the same.

Correct me if I'm wrong, but wasn't the MD5 certificate hack presented
back at 25C3 based on exactly that scenario? They used the serial number
and timestamp or some other such thing (don't recall the details) as
weak spots and then sent loads of certificate requests to the CA to
effecively brute-force it.

(Of course, CAs are now required to randomize their serial number, so
since that particular attack isn't possible anymore, I agree that for
the time being it's still not a feasible scenario for SHA1, but hey)

--
Wouter Verhelst
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rejecting SHA-1 certificates

Niklas Keller
2017-07-12 8:35 GMT+02:00 Wouter Verhelst <[hidden email]>:
On 11-07-17 23:44, Salz, Rich via openssl-users wrote:
>> It's very well worth the effort, otherwise there's a security issue, because certificates can be forged.
>
> No they cannot.
>
> What *has* been done is a document was created with "weak spots" and another document was created that  changed those weak spots, but the digest was the same.

Correct me if I'm wrong, but wasn't the MD5 certificate hack presented
back at 25C3 based on exactly that scenario? They used the serial number
and timestamp or some other such thing (don't recall the details) as
weak spots and then sent loads of certificate requests to the CA to
effecively brute-force it.

(Of course, CAs are now required to randomize their serial number, so
since that particular attack isn't possible anymore, I agree that for
the time being it's still not a feasible scenario for SHA1, but hey)

Maybe not currently for SHA-1, but maybe for MD5?

Also not sure whether you can use these old certificates with weak serials and change the date as well there?

Regards, Niklas 

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rejecting SHA-1 certificates

Jakob Bohm-7
On 12/07/2017 14:24, Niklas Keller wrote:

> 2017-07-12 8:35 GMT+02:00 Wouter Verhelst <[hidden email]
> <mailto:[hidden email]>>:
>
>     On 11-07-17 23:44, Salz, Rich via openssl-users wrote:
>     >> It's very well worth the effort, otherwise there's a security
>     issue, because certificates can be forged.
>     >
>     > No they cannot.
>     >
>     > What *has* been done is a document was created with "weak spots"
>     and another document was created that changed those weak spots,
>     but the digest was the same.
>
>     Correct me if I'm wrong, but wasn't the MD5 certificate hack presented
>     back at 25C3 based on exactly that scenario? They used the serial
>     number
>     and timestamp or some other such thing (don't recall the details) as
>     weak spots and then sent loads of certificate requests to the CA to
>     effecively brute-force it.
>
>     (Of course, CAs are now required to randomize their serial number, so
>     since that particular attack isn't possible anymore, I agree that for
>     the time being it's still not a feasible scenario for SHA1, but hey)
>
>
> Maybe not currently for SHA-1, but maybe for MD5?
>
> Also not sure whether you can use these old certificates with weak
> serials and change the date as well there?
I think the attack was to request a certificate at exactly the right
moment to get a certificate with a date/serial combination that fit
a known hash collision value.  Making the serial contain a lot of
random bits that the requester cannot predict or control prevents
that particular attack from working.

So it's not a matter of "weak serials", but preventing "chosen
serials", at least for the currently known attack on MD5 CAs and
presumed to work against likely initial attacks on SHA-1 CAs,
especially such attacks made before the last trusted CA stops
issuing new certs (about a year ago for SSL, still ongoing for
other cert purposes due to important clients stuck without
stronger hash algorithms in their non-upgradable crypto code).

Because the fake certificate need not be for the same purpose as
the real certificate, to get a fake SSL cert, it may be enough
to attack issuance of non-SSL SHA-1 certs from a CA trusted for
SSL certs.  This is exacerbated if using an OpenSSL version that
makes insufficient checks as to what each CA cert in the chain is
trusted to issue.  Also many installations provide a single
list/directory of CA certs not subdivided by trust purpose.

These doubts and weaknesses are good reason to add an extra check
for weak hash algorithms to the chain validation, either in OpenSSL
or in an application.  At least as a defense in depth.  Of cause
adding this in OpenSSL itself would have to be configurable for
situations partially outside the public trust environment, such
as talking to IoT devices with old crypto libraries and
rechecking/decrypting S/MIME mails received years ago.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Loading...