• Adam Langley's avatar
    crypto/tls: decouple handshake signatures from the handshake hash. · 09b238f1
    Adam Langley authored
    Prior to TLS 1.2, the handshake had a pleasing property that one could
    incrementally hash it and, from that, get the needed hashes for both
    the CertificateVerify and Finished messages.
    
    TLS 1.2 introduced negotiation for the signature and hash and it became
    possible for the handshake hash to be, say, SHA-384, but for the
    CertificateVerify to sign the handshake with SHA-1. The problem is that
    one doesn't know in advance which hashes will be needed and thus the
    handshake needs to be buffered.
    
    Go ignored this, always kept a single handshake hash, and any signatures
    over the handshake had to use that hash.
    
    However, there are a set of servers that inspect the client's offered
    signature hash functions and will abort the handshake if one of the
    server's certificates is signed with a hash function outside of that
    set. https://robertsspaceindustries.com/ is an example of such a server.
    
    Clearly not a lot of thought happened when that server code was written,
    but its out there and we have to deal with it.
    
    This change decouples the handshake hash from the CertificateVerify
    hash. This lays the groundwork for advertising support for SHA-384 but
    doesn't actually make that change in the interests of reviewability.
    Updating the advertised hash functions will cause changes in many of the
    testdata/ files and some errors might get lost in the noise. This change
    only needs to update four testdata/ files: one because a SHA-384-based
    handshake is now being signed with SHA-256 and the others because the
    TLS 1.2 CertificateRequest message now includes SHA-1.
    
    This change also has the effect of adding support for
    client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
    default so this should be moot.
    
    It would be possible to avoid much of this change and just support
    SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
    and SKX params (a design mistake in TLS). However, that would leave Go
    in the odd situation where it advertised support for SHA-384, but would
    only use the handshake hash when signing client certificates. I fear
    that'll just cause problems in the future.
    
    Much of this code was written by davidben@ for the purposes of testing
    BoringSSL.
    
    Partly addresses #9757
    
    Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
    Reviewed-on: https://go-review.googlesource.com/9415
    Run-TryBot: Adam Langley <agl@golang.org>
    Reviewed-by: 's avatarAdam Langley <agl@golang.org>
    09b238f1
Name
Last commit
Last update
api Loading commit data...
doc Loading commit data...
lib/time Loading commit data...
misc Loading commit data...
src Loading commit data...
test Loading commit data...
.gitattributes Loading commit data...
.gitignore Loading commit data...
AUTHORS Loading commit data...
CONTRIBUTING.md Loading commit data...
CONTRIBUTORS Loading commit data...
LICENSE Loading commit data...
PATENTS Loading commit data...
README.md Loading commit data...
favicon.ico Loading commit data...
robots.txt Loading commit data...