a54e2e85ee
I found no users of this. We can restore it if needbe, but I don't expect anyone to find it useful in its current form. The API is suspect for the same reasons DTLSv1_listen was. An SSL object is stateful and assumes you already have the endpoint separated out. If we ever need it, server-side HelloVerifyRequest and DTLSv1_listen should be implemented by a separate stateless listener that statelessly handles cookieless ClientHello + HelloVerifyRequest. Once a ClientHello with a valid cookie comes in, it sets up a stateful SSL object and passes control along to that. Change-Id: I86adc1dfb6a81bebe987784c36ad6634a9a1b120 Reviewed-on: https://boringssl-review.googlesource.com/3480 Reviewed-by: Adam Langley <agl@google.com> |
||
---|---|---|
.. | ||
alert.go | ||
cert.pem | ||
channel_id_key.pem | ||
cipher_suites.go | ||
common.go | ||
conn.go | ||
dtls.go | ||
ecdsa_cert.pem | ||
ecdsa_key.pem | ||
handshake_client.go | ||
handshake_messages.go | ||
handshake_server.go | ||
key_agreement.go | ||
key.pem | ||
packet_adapter.go | ||
prf.go | ||
recordingconn.go | ||
runner.go | ||
ticket.go | ||
tls.go |