generateKeyShare has nothing to do with Config receiver. It doesn't
configure anything. It has everything with connection so moved to Conn.
Making deriveECDHESecret also a method of Conn will make it possible to
access 'isClient' field.
* Implements verifyPeerCertificate common for client and server
* Removes processCertsFromServer13 and processCertsFromClient13
and implements getCertsFromEntries common to server and client
which is used instead.
Send/Skip CCS, set legacy record version to 3,3 and echo session ID.
CCS must be ignored while the handshake is running, but not thereafter:
https://tools.ietf.org/html/draft-ietf-tls-tls13-22#section-5
Unconditionally send CCS as server because bogo requires it, even if no
session ID is included in the Client Hello. TLS 1.3 clients MUST ignore
it anyway, so it should not hurt.
Fixes interop with boringssl and openssl and passes bogo.
Draft 21 changed end_of_early_data from an alert into a handshake
message to allow it to integrate better with the handshake. This change
does that, rather than handling EOD at the record layer, it moves
processing up to the actual readers of (early) application data.
D19: use early_data instead of custom ticket_early_data_info extension
codepoint. D21: new ticket nonce field and change in PSK calculation.
This nonce provides some minor security advantage in case one of the PSK
is compromised (which would leak the resumption master secret).
Rename "resumptionSecret" to "pskSecret" in sessionState13 to reflect
the D21 change and use constant-time comparison for the secret.
Also fix potential panic if the ticket is large enough, but the
extensions are missing.
D19 added an additional pre-extract Derive-Secret stage. D20 shortened
labels. Bump from D18 to D21 with no backwards compat option for now
since older drafts are considered undeployable.
Support validation of ECDSA and RSASSA-PSS signatures. Explicitly do not
support PKCS1-v1_5 signatures since these are not allowed for handshake
messages.
Advertise TLS 1.3 in supported_versions and send a key share for the
first preferred curve. Missing are HRR, certificate validation and
Encrypted Extensions processing (see TODO notes).
For simplicity only a single key share is remembered. This key share
should be updated with a HRR (when implemented).
This change splits handshake processing for TLS 1.3, reindenting the TLS
1.2 code path and splitting initializationg of the handshake hash. No
equivalent is added for processServerHello because session resumption is
not supported yet.
All TLS 1.3 cipher suites so far use a nonce length of 12, but that does
not have to be the case. Correct the cipher suite definition and use it.
Spec: https://tools.ietf.org/html/draft-ietf-tls-tls13-22#section-5.3
Note: there is no functional change, the values were previously unused.
Fixes: ("[dev.tls] crypto/tls: implement TLS 1.3 cipher suites")
Disable 0.5-RTT as it has weaker security properties than 1-RTT. The
same security considerations from TLS False Start (RFC 7918) apply.
Currently the server Handshake method returns as soon as it has sent its
parameters, but it does not wait for the client to authenticate the
handshake via a Finished message. This broke a test that assumed that
the Handshake message performs a full handshake and also
(unintentionally?) enabled the server to send application data before
the handshake is complete ("0.5-RTT data").
Fix this by moving the implicit Finished message check in the handshake
message reader to the server handshake itself (previously readRecord
would process the Finished message as a side-effect of requesting
recordTypeApplicationData). And in the special case where 0-RTT data is
actually desired, process the Finished message in the ConfirmHandshake
and Read functions.
NOTE: 0.5-RTT is not disabled when the server enables 0-RTT. It is the
server responsibility to use ConfirmHandshake before writing anything.
Explicitly panic when ConfirmHandshake is used for client connections,
this is not the intended use of that API.
Merge serverHelloMsg13 into serverHelloMsg in preparation for draft 22.
This will also simplify the client implementation since only one
structure has to be checked.
Also fixed potential out-of-bounds access with keyShare unmarshal.
Merge upstream go post-1.9 crypto/tls changes from master:
d8ee5d11e5 crypto/tls: limit number of consecutive warning alerts
96cd66b266 crypto/tls: advertise support for SHA-512 signatures in 1.2
f265f5db5d archive/zip, crypto/tls: use rand.Read instead of casting ints to bytes
54d04c2fcb crypto/tls: remove bookkeeping code from pHash function
d1bbdbe760 crypto/tls: replace signatureAndHash by SignatureScheme.
cb3b345209 crypto/tls: fix first byte test for 255 CBC padding bytes
d153df8e4b all: revert "all: prefer strings.LastIndexByte over strings.LastIndex"
5e42658fc0 all: prefer bytes.IndexByte over bytes.Index
d2826d3e06 all: prefer strings.LastIndexByte over strings.LastIndex
5a986eca86 all: fix article typos
0f9a2cf2c4 crypto/tls: fix clientHelloMsg fuzzer not to generate the RI SCSV
e7d46cee2f crypto/tls: fix and expand TestVerifyPeerCertificate and TestGetClientCertificate
85deaf6077 crypto/tls: fix docstring of Config.ClientSessionCache
4a5f85babb crypto/tls: disallow handshake messages fragmented across CCS
b3465646ff crypto/tls: add BenchmarkHandshakeServer
d38d357c78 crypto/tls: don't check whether an ec point is on a curve twice
e085a891f0 crypto/tls: split clientHandshake into multiple methods
Conflicts:
* handshake_client.go: conflict between our ("crypto/tls: allow client to
pick TLS 1.3, do not enable it by default.") and upstream
("crypto/tls: split clientHandshake into multiple methods"), resolve
by applying the mutualVersion->pickVersion change in pickTLSVersion.
* handshake_server.go: trivial conflict due to upstreamed patch
("crypto/tls: replace signatureAndHash by SignatureScheme.") and
("crypto/tls: implement TLS 1.3 server 0-RTT") which added pskBinder.
Other merge changes:
* tls13.go: signatureAndHashes as added in ("crypto/tls: implement TLS
1.3 minimal server") was renamed as required by ("crypto/tls: replace
signatureAndHash by SignatureScheme.").
* handshake_client.go: moved check from ("crypto/tls: check that client
cipher suite matches version") to pickCipherSuite as required by
("crypto/tls: split clientHandshake into multiple methods").
Use the new keySchedule13 type instead of hash.Hash to avoid tracking
the hashContext and intermediate secrets manually.
checkPSK is modified not to return the calculated early secret, this is
internal to keySchedule13 now. The caller just learns whether it was
resumed using a PSK or not.
In order to reduce repetitive complexity (extract handshake context,
pass the right secrets around to calculate a secret and build a cipher),
create a new type that tracks the hash type, the handshake context and
intermediate secrets.
Advantages: facilitates reuse between client and server code, makes it
easier to update labels for draft-19, makes it easier to add central
KeyLogWriter functionality.
There should be no data in the Handshake buffer on encryption state
changes (including implicit 1.3 transitions). Checking that also blocks
all Handshake messages fragmented across CCS.
BoGo: PartialClientFinishedWithClientHello
Phase should only be accessed under in.Mutex. Handshake and all Read
operations obtain that lock. However, many functions checking for
handshakeRunning only obtain handshakeMutex: reintroduce
handshakeCompleted for them. ConnectionState and Close check for
handshakeConfirmed, introduce an atomic flag for them.
