2c66e079ab
access_denied is only used to indicate client cert errors and Chrome maps it to ERR_SSL_BAD_CLIENT_AUTH_CERT accordingly: access_denied A valid certificate was received, but when access control was applied, the sender decided not to proceed with negotiation. This message is always fatal. We don't appear to be the cause of Chrome's recent ERR_SSL_BAD_CLIENT_AUTH_CERT spike, but we should send these correctly nonetheless. If the early callback fails, handshake_failure seems the most appropriate ("I was unable to find suitable parameters"). There isn't really an alert that matches DoS, but internal_error seems okay? internal_error An internal error unrelated to the peer or the correctness of the protocol (such as a memory allocation failure) makes it impossible to continue. This message is always fatal. There's nothing wrong, per se, with your ClientHello, but I just can't deal with it right now. Please go away. Change-Id: Icd1c998c09dc42daa4b309c1a4a0f136b85eb69d Reviewed-on: https://boringssl-review.googlesource.com/11084 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> |
||
---|---|---|
.. | ||
curve25519 | ||
newhope | ||
poly1305 | ||
alert.go | ||
cert.pem | ||
chacha20_poly1305_test.go | ||
chacha20_poly1305.go | ||
channel_id_key.pem | ||
cipher_suites.go | ||
common.go | ||
conn.go | ||
deterministic.go | ||
dtls.go | ||
ecdsa_p256_cert.pem | ||
ecdsa_p256_key.pem | ||
ecdsa_p384_cert.pem | ||
ecdsa_p384_key.pem | ||
ecdsa_p521_cert.pem | ||
ecdsa_p521_key.pem | ||
handshake_client.go | ||
handshake_messages.go | ||
handshake_server.go | ||
hkdf_test.go | ||
hkdf.go | ||
key_agreement.go | ||
key.pem | ||
packet_adapter.go | ||
prf.go | ||
recordingconn.go | ||
rsa_1024_cert.pem | ||
rsa_1024_key.pem | ||
runner_test.go | ||
runner.go | ||
sign.go | ||
test_output.go | ||
ticket.go | ||
tls.go |