| 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a few 'feature tests' to Protocol_Version which helps avoid some
explicit comparisons. Additionally, remove the relational comparisons,
except for operator> which is still used in a few locations.
TLS::Policy has changed and no longer has min_version. The new hook
that replaces it is acceptable_protocol_version, which should return
true if and only if we are willing to negotiate the version
returned. This leads to a somewhat cleaner result and additionally
allows one to do maybe interesting though mostly useless things like
allowing TLS 1.0 or 1.2 but not 1.1.
Fix the version sent in the (unused) DTLS hello verify message.
|
|
|
|
|
|
| |
X is true" and "assertion X is false". Convert all of them to the form
"assertion X is true" thus making it clear what it is that we are
attempting to assert by testing the expression provided.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
needed to derive from it. Add a new overload of send taking a
std::string for convenience (eg client.send("GET / HTTP/1.0\n\r")).
Let Channel::renegotiatate's force_full_renegotiation argument default
to false.
Fix a bug where if we negotiated TLS v1.2 and our Policy was
configured to only use MD5 we would send an empty allowed signatures
which is maybe bogus or maybe just ambigious (RFC is unclear, though
we reject in this case). To fix this, support putting MD5 in the
signature algorithms extension, and then in choose_sig_format order
first by our hash preference, and only allow hashes that are allowed
by policy. Thus is a client claims to support both SHA-2 and MD5 we'll
choose SHA-2 even if the client put MD5 first (some versions of GnuTLS
ordered the list backwards due to a bug, so this is actually a useful
behavior).
|
|
|
|
| |
attacks and in general detect invalid messages.
|
|
|
|
| |
style cast in secmem.h
|
|
|
|
|
|
| |
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.
|
| |
|
|\
| |
| |
| |
| |
| | |
a4741cd07f50a9e1b29b0dd97c6fb8697c038ade)
to branch 'net.randombit.botan.cxx11' (head 116e5ff139c07000be431e07d3472cc8f3919b91)
|
| |
| |
| |
| |
| |
| | |
Add SRP hooks in the examples
Fix next protocol support in the tls_server example.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Initial outline of server side SRP support. Need to figure out how to
transfer the v, b, B params from the server key exchange message to
the client key exchange. The DH variants do this by passing a
Private_Key via server_kex_key call, but wrapping SRP params in a
Private_Key really doesn't feel right. Not sure what to do here.
Possibly both SRP and DH should return a Key_Exchange_Material* that a
client key exchange knows how to dynamic cast on.
|
| |
| |
| |
| |
| | |
1.0.1, only the certificate versions tested currently as OpenSSL
doesn't support anon SRP.
|
|\|
| |
| |
| |
| |
| | |
63b88a65b699c95ef839bc18336bceccfbfabd2e)
to branch 'net.randombit.botan.cxx11' (head 1adcc46808b403b8f6bf1669f022e65f9c30e8ea)
|
| | |
|
| |
| |
| |
| | |
and unique_ptr.
|
|/
|
|
|
|
| |
0ceb9cde62a2b3614901ae85a53546d9fc641326)
to branch 'net.randombit.botan.cxx11' (head 777e65950ef3706a82e5df20dcca7fcc999ca533)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
the Alert class for namespacing.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
credentials server to return a new copy each time which is slow and
mostly pointless. Instead, specify that the key remains owned by the
credentials manager.
This is theoretically an issue if you have thousands of keys to
manage; the credentials server doesn't actually know when they have
gone out of scope until its destructor runs. So it could be forced to
use a lot of memory in the meantime. I'm not sure that this is a case
worth optimizing for, at least until someone comes along who actually
has this as a problem.
|
|
|
|
|
| |
server handshake flow and into the server and client key exchange
message types. It already was hidden from the client handshake code.
|
|
|
|
|
|
|
| |
there.
Only named curves supported, likely won't ever support explicit curves
cause that's just asking for problems.
|
|
|
|
|
|
| |
That happens to be true for DH and export RSA key exchanges but isn't
true for ECDH or SRP. (It's almost true for SRP, but if the salt had a
leading zero byte it would be lost in the conversion).
|
|
|
|
| |
for such a minor change.
|
|
|
|
|
| |
everything into a new namespace (Botan::TLS), removing the TLS_
prefixes on everything.
|
|
|
|
|
| |
the client key exchange object to interpret the message on the basis
of the chosen ciphersuite.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
counterparty by using the highest preference hash they have available
for the signature type we are generating. This does mean we will do
stupid things, if the counterparty is stupid (for instance some
versions of GnuTLS will prefer SHA-1 over the SHA-2s - likely someone
misread the spec and ordered the list backwards). But because we
filter out MD5 we'll never use that; even in the worst case, if
someone requests only MD5, we'll skip over it and use SHA-1 as the
fallback algorithm. Theoretically this is against the spec because we
"MUST" send something compatible, but seriously, fuck em. Right in the
eye.
|
|
|
|
| |
older versions.
|
|
|
|
|
|
|
|
| |
the ciphersuite code and a set of strings specifying the underlying
suite algorithms. Remove it entirely.
Some things are likely broken. One I know about is that we always send
the hash/signature type indicator but should only do so for TLS >= 1.2
|
|
|
|
|
|
| |
remain broken.
New interface for querying the TLS extensions, much cleaner.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
TLS 1.0/1.1, SSLv3 uses a different hash format. Only RSA certs tested
so far.
|
| |
|
|
|