| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
This is mostly just a minor code savings for TLS, but it actually
seems important for DTLS because getting a handshake message can be a
trigger for retransmitting previously sent handshake messages in some
circumstances. Having the reading and writing all in one layer makes
it a bit easier to accomplish that.
|
| |
|
|
| |
that task to Record_Writer. Needed for DTLS work.
|
| |
|
|
|
|
| |
using a custom allocator. Currently our allocator just does new/delete
with a memset before deletion, and the mmap and mlock allocators have
been removed.
|
| |\
| |
| |
| |
| |
| | |
63b88a65b699c95ef839bc18336bceccfbfabd2e)
to branch 'net.randombit.botan.cxx11' (head 1adcc46808b403b8f6bf1669f022e65f9c30e8ea)
|
| | |
| |
| |
| |
| |
| |
| |
| | |
quite differently).
Avoid using a queue for reading certificates.
Hide the version code in the handshake state with a getter and setter.
|
| | | |
|
| |/
|
|
| |
and unique_ptr.
|
| |
|
|
| |
ciphersuites.
|
| |
|
|
| |
the Alert class for namespacing.
|
| |
|
|
| |
for such a minor change.
|
| |
|
|
|
| |
everything into a new namespace (Botan::TLS), removing the TLS_
prefixes on everything.
|
| |
|
|
|
|
|
|
|
| |
SSLv3 handshakes: we need to copy the handshake state when we computed
the finished data in the SSLv3 case because we need to add a little
bit of data onto the end, but we don't want to include that data with
the next computation. This meant that the finished message a client
sent us was fine, but the one we sent out had a bad finished value and
was rejected.
|
| |
|
|
|
|
|
|
| |
basic connection with a GnuTLS server does work. Currently we don't
respect the signature_algorithms extension at all, and using SHA-256
with a 12-byte finished value is hardcoded though the spec is that it
can depend on the ciphersuite (likely relevant for GOST ciphersuites
in particular).
|
| |
|
|
|
|
| |
Instead deserialize directly in the constructors that are passed the
raw message data. This makes it easier to pass contextual information
needed for decoding (eg, version numbers) where necessary.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
extension (client side only at the moment). Add an interface that
allows applications to request renegotiation.
|
| | |
|
| |
|
|
|
| |
TLS 1.0/1.1, SSLv3 uses a different hash format. Only RSA certs tested
so far.
|
| | |
|
| |
|
