New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 700047 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Regression



Sign in to add a comment

An empty TLS SCT extension causes a TLS Error

Reported by t...@ritter.vg, Mar 9 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:51.0) Gecko/20100101 Firefox/51.0

Example URL:
https://utternoncesense.com/

Steps to reproduce the problem:
1. Visit https://utternoncesense.com/ in Canary. Observe the error.
2. Visit https://utternoncesense.com/ on Chrome release (56) - observe you get the 'Invalid date' SSL error (cause my cert's out of date on that particular domain.

What is the expected behavior?
You should complete the TLS connection (in this case, get the invalid cert error.)

What went wrong?
I had this same error on another domain https://asac.casa and it went away after I fed an SCT in to be returned. So I'm deducing that either Chrome or Apache is handling the 'empty SCT list' case incorrectly. 

Did this work before? Yes I don't remember. It works in 56 though?

Chrome version: Version 59.0.3036.0 (Official Build) canary (64-bit)  Channel: canary
OS Version: OS X 10.12
Flash Version: Shockwave Flash 23.0 r0

 
Components: -Internals>Network Internals>Network>Certificate
I can reproduce this on Canary (59.0.3035.0).  net-internals says:

t=21676 [st=20]        SSL_HANDSHAKE_ERROR
                       --> error_lib = 16
                       --> error_reason = 149
                       --> file = "c:\\b\\build\\slave\\win64-pgo\\build\\src\\third_party\\boringssl\\src\\ssl\\t1_lib.c"
                       --> line = 3035
                       --> net_error = -107 (ERR_SSL_PROTOCOL_ERROR)
                       --> ssl_error = 1
Labels: -OS-Mac OS-All
Oh, and I can repro on Windows, so presumably a cross-platform issue.
Cc: svaldez@chromium.org
Components: -Internals>Network>Certificate Internals>Network>SSL
Owner: davidben@chromium.org
david/steven - did y'all reorder the CT extension so it appears first/last and tickles the WebSense bug?
No, that has nothing to do with this failure mode. This is us rejecting the CT extension the server is sending because we validate it nowadays. Looking...
Your server is violating the specification. See RFC 6962, section 3.3:
https://tools.ietf.org/html/rfc6962#section-3.3

The sct_list field of the SignedCertificateTimestampList structure may not be empty. (Nor can the SerializedSCT itself.) If you don't have any SCTs to send, you shouldn't be sending the extension at all.
Status: WontFix (was: Unconfirmed)
Oh, right, server-sent message, not client-sent.

Comment 7 by t...@ritter.vg, Mar 9 2017

For reference, this bug is now over at https://bz.apache.org/bugzilla/show_bug.cgi?id=60843

Thanks/Sorry - since Chrome Release accepted it, I thought it was a regression.

Sign in to add a comment