Re: [openssl-users] Issue with TLS1.3 and s_time

[Roelof Du Toit]

This seems to be a bug in how s_time handles the TLS 1.3 post-handshake 
NewSessionTicket message; more specifically: not handling the retry when 
SSL_read() returns -1.

The following diff (in tls1.3-draft-19 branch) appears to resolve the issue:

$ git diff
diff --git a/apps/s_time.c b/apps/s_time.c
index 998ef72..caa1b22 100644
--- a/apps/s_time.c
+++ b/apps/s_time.c
@@ -234,8 +234,8 @@ int s_time_main(int argc, char **argv)
fmt_http_get_cmd, www_path);
 if (SSL_write(scon, buf, buf_len) <= 0)
 goto end;
-while ((i = SSL_read(scon, buf, sizeof(buf))) > 0)
-bytes_read += i;
+while ((i = SSL_read(scon, buf, sizeof(buf))) > 0 || 
BIO_should_retry(SSL_get_rbio(scon)))
+if (i > 0) bytes_read += i;
 }


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

Re: [openssl-users] Issue with TLS1.3 and s_time

[Salz, Rich via openssl-users]

In TLS 1.3 the “time” field went away.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Rejecting SHA-1 certificates

[Jakob Bohm]

On 12/07/2017 14:24, Niklas Keller wrote:
2017-07-12 8:35 GMT+02:00 Wouter Verhelst >:


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

Re: [openssl-users] Rejecting SHA-1 certificates

[Niklas Keller]

2017-07-12 8:35 GMT+02:00 Wouter Verhelst :

> 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

Re: [openssl-users] Rejecting SHA-1 certificates

[Wouter Verhelst]

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