| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Add getters for major and minor protocoll version on TLS_Session.
Add Certificate_Type code points for ECC certs.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
stripped out. Would cause failures with DHE in one out of every few
hundred connection attempts where the finished message would not
decrypt properly and the handshake would be rejected.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
counterparty might want to send us a matching close notify under the
currently existing key state. New logic is if we send the alert our
writer is reset (we will send nothing more), but leave the reader as
is. The reader will then be reset if and when we get a close notify,
or if the counterparty doesn't send one, we'll just end the connection
normally. This will also deal with the case where there is some
application data queued still in the recv buffer.
Don't close in ~TLS_Channel: applications should do this explicitly
when the application-level protocol is ended. Otherwise we'd send a
close_notify upon, for instance, an uncaught exception unwinding the
stack.
Add an enum for the maximum size of any TLS ciphertext packet
including header. Handy for apps.
If we get a bad alert size report size we got.
|
|
|
|
|
|
|
| |
into for comparison. This eliminates the last memory allocation in the
record processing layers except of course the elephant that the Pipe
doing the ciphering will copy its input. That's an issue for
Pipe/Filter 2.0 though.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pure RSA ciphersuite was negotiated.
Detection of version rollback attacks with pure RSA ciphersuites was
incorrect and would cause failures if the client supported a version
we didn't (eg GnuTLS with TLS 1.2 enabled).
Improve detection of SSLv2 client hellos. In particular, if a client
that only supports SSLv2 connects, we will detect this case and send a
protocol_version alert (which the SSLv2-only client will not
understand, but a packet analyzer probably will) plus an exception
with the message "Client claims to only support SSLv2, rejecting"
instead of the previous much less helpful "Unknown record type"
message.
Remove vestigial support for RSA export ciphersuite key exchange.
|
|
|
|
|
| |
handshake callback info instead. Clean up the buffer consumption code
in the record reader.
|
| |
|
|
|
|
|
|
| |
expense of significant complexity. Needs careful testing for corner
cases and malicious inputs, but seems to work well with randomly
chosen segmentations in a correctly formatted stream at least.
|
|
|
|
|
| |
enforce the 2^14 byte plaintext limit in the reader (previously only
the 2^14+2048 byte ciphertext size limit was enforced).
|
|\
| |
| |
| |
| |
| | |
423204c45c686bfba0058cdc65b40b5bdfae5fb8)
to branch 'net.randombit.botan.tls-state-machine' (head 3eb85687ada277da96946fa38a8f6993977583f0)
|
| |
| |
| |
| |
| | |
by TLS (relies on the finished message check). Add a class for reading
files created by GnuTLS's srptool.
|
| |
| |
| |
| |
| | |
loop (size_t overflow), likely causing a segfault. Not exploitable as
far as I can tell, beyond the obvious crashing.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently has the same behavior in client and server; if we got a
NO_RENEGOTIATION alert, and we appear to be renegotiating, delete the
state if it exists.
Noticed when talking to OpenSSL 0.9.8g which rejects all renegotiation
requests.
|
| |
| |
| |
| | |
traffic.
|
| | |
|
| |
| |
| |
| |
| | |
completes. The client gets a callback when the handshake is complete
so they can know exactly when it's OK to send.
|
| |
| |
| |
| | |
per-se, it's a notification by the client. Rename accordingly.
|
| |
| |
| |
| |
| |
| | |
a timestamp. Instead we used random values for all, but hypothetically
it would be useful for the timestamp to be correct in case someone
decides to interpret that field. Which they hopefully won't.
|
| |
| |
| |
| |
| |
| | |
Add support for NPN on the server side. Server is initialized with the
list of protocols it wants to offer, once the handshake completes the
client requested protocol is available via a getter.
|
| |
| |
| |
| | |
tested with google.com:443
|
| | |
|
| |
| |
| |
| |
| | |
the cache. The current handshake will complete, but the session can
not be resumed later.
|
| | |
|
| |
| |
| |
| | |
specifying if the session should be saved to the session cache.
|
| |
| |
| |
| |
| | |
what certs, keys, etc are available to the app. Needs polishing but it
seems like it should be sound.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
untested though.
|
| |
| |
| |
| | |
its own file. Rename tls_state to tls_handshake_state.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Add a new callback that is called with the session info when a
handshake completes. Currently only called on the server side as
the client doesn't have session resumption yet.
Rename CipherSuite to TLS_Cipher_Suite.
|
| |
| |
| |
| |
| |
| |
| | |
on the client side at the moment. Tested with gnutls-cli --recordsize.
Save the fragment size and the secure renegotiation flags in the
session state.
|
| |
| |
| |
| |
| | |
has been completed and if the connection has been definitely closed by
a fatal alert or a close notify.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
client and server. Server side can handle SCSV values as well,
client always sends the extension instead.
Handle an empty SNI extension coming back from the server - this is
used to indicate that it understood the name. Also add better checking
for extensions by passing in what the supposed size of the extension
is.
Only send the secure negotiation extension in the server hello if the
client indicated support for it.
|
| | |
|
| |
| |
| |
| |
| | |
extension (client side only at the moment). Add an interface that
allows applications to request renegotiation.
|
| |
| |
| |
| | |
meant up until this point, renegotiation never worked. :(
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Add support for sending and reading the SRP identifier extension.
Add some helper classes for managing TLS extensions
Add ciphersuite codes for SRP key exchange.
|
| | |
|
| |
| |
| |
| | |
client cert and they don't have one.
|
| | |
|
| |
| |
| |
| |
| |
| | |
only be affected if the attacker can modify the handshake messages, which
seems fairly unlikely, and some implementations are known to be unhappy
with fragmented handshakes.
|