| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
entire handshake state in many cases makes things simpler to update,
in that each message type already knows what it needs depending on the
version, params, etc, and this way a) that knowledge doesn't need to
percolate up the the actual client and server handshake code and b)
each message type can be updated for new formats/version without
having to change its callers. Downside is it hides the dependency
information away, and makes it non-obvious what needs to be created
beforehand for each message to work correctly. However this is
(almost) entirely predicated on the handshake message flows, and these
we control with the next expected message scheme, so this should be
fairly safe to do.
This checkin only updates the ones where it was immediately relevant
but for consistency probably all of them should be updated in the same
way.
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
| |
| |
| | |
OpenSSL's s_client instead of just doing a one-shot request.
|
| |
| |
| |
| |
| | |
has been completed and if the connection has been definitely closed by
a fatal alert or a close notify.
|