| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
everything into a new namespace (Botan::TLS), removing the TLS_
prefixes on everything.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
handshake callback info instead. Clean up the buffer consumption code
in the record reader.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
completes. The client gets a callback when the handshake is complete
so they can know exactly when it's OK to send.
|
| |
|
|
| |
specifying if the session should be saved to the session cache.
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
|
| |
has been completed and if the connection has been definitely closed by
a fatal alert or a close notify.
|
| |
|
|
|
| |
extension (client side only at the moment). Add an interface that
allows applications to request renegotiation.
|
| | |
|
|
|
Also delete the obsolete/never worked CMS examples
|
