aboutsummaryrefslogtreecommitdiffstats
path: root/src/tls/tls_messages.h
Commit message (Collapse)AuthorAgeFilesLines
* Add Handshake_Hash::resetlloyd2012-08-031-3/+7
| | | | Add cookie support in Client_Hello.
* Combine Handshake_Writer and Handshake_Reader into Handshake_IO.lloyd2012-08-031-15/+15
| | | | | | | | 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.
* Add a class that handles writing handshake messages instead of pushinglloyd2012-07-161-16/+15
| | | | that task to Record_Writer. Needed for DTLS work.
* Add TLS::Policy::minimum_dh_group_size, default 1024. Send anlloyd2012-06-251-0/+1
| | | | | | | | insufficient_security alert if the server tries to give us a DH group smaller than that. Also check to make sure the key isn't obviously bogus (<=1 || >= p-1), though as the key is purely ephemeral it doesn't seem like a small subgroup attack would provide much advantage anyway.
* Make TLS::Channel::send non-virtual as neither Client nor Serverlloyd2012-06-181-0/+1
| | | | | | | | | | | | | | | | | | | 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).
* A fix for bug 192. First, when renegotiating in the client, attempt tolloyd2012-06-091-0/+1
| | | | | | | | | | | | | | | | | | | renegotiate using our currently negotiated version instead of our preferred version. It turns out that neither OpenSSL nor GnuTLS like clients changing the version between negotiations, both send a protocol_version alert. So we probably want to avoid doing that. On the server side, handle a client sending inconsistent versions as best we can. If the client attmepts to renegotiate a session using a later version, return a server hello with their original version (this is what OpenSSL does). If they attempt to renegotiate using an earlier version, send a fatal alert and close the connection, since this seems like a dubious thing to do. Also, fix the situation where we as a TLS v1.0 server (because of configuration) are talking to a TLS v1.2 client. We would still use their signature_algorithms extension and send a SHA-256 (or whatever) signature!
* Replace 0 and NULL pointer constants with nullptr. Also fix an oldlloyd2012-05-181-1/+1
| | | | style cast in secmem.h
* Fairly huge update that replaces the old secmem types with std::vectorlloyd2012-05-181-60/+61
| | | | | | 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.
* Add a bool param to renegotiate on if we should force a fulllloyd2012-04-181-0/+1
| | | | | | | renegotiation or not. Save the hostname in the client so we can pull the session from the session manager.
* Add support for TLS heartbeats (RFC 6520). Heartbeat initiations fromlloyd2012-04-161-15/+22
| | | | | | | | | | | | | the peer are automatically responded to. TLS::Channel::heartbeat can initiate a new heartbeat if the peer allows it. Heartbeat replies are passed back to the application processing function with an Alert value of HEARTBEAT_PAYLOAD (a 'fake' value, 256, which is out of range of the valid TLS alert space), along with the sent payload. The RFC requires us to have no more than one heartbeat 'in flight' at a time, ie without getting a response (or a timeout in the case of DTLS). Currently we do not prevent an application from requesting more.
* Finish up server side SRP support, a little ugly but it works.lloyd2012-04-061-1/+6
| | | | | | Add SRP hooks in the examples Fix next protocol support in the tls_server example.
* Initial client-side support for SRP (finally!). Tested against OpenSSLlloyd2012-04-051-0/+1
| | | | | 1.0.1, only the certificate versions tested currently as OpenSSL doesn't support anon SRP.
* Limit the lifetime of tickets to Policy::session_ticket_lifetime()lloyd2012-04-041-23/+10
| | | | | | | | | | | | | | | | | seconds and report that value to the client in the NewSessionTicket message. After that point, a session ticket is ignored and a full renegotiation is forced. Only send a new session ticket on a new session, or on a resumed session where the client indicated it supports session tickets but for whatever reason didn't send one in the hello. Perhaps in this case, we should also remove the session from the session manager? Clean up server selection of the ciphersuite a bit, all in an anon function in tls_server instead of scattered over Server, Policy, and Server_Hello. Add Session::session_age and Session_Manager::session_lifetime
* Revert the session_ticket callback in credentials manager. If a PSKlloyd2012-03-231-0/+1
| | | | | | | | | | | manager is being used, it could be easily used for session tickets as well, and if it's not the generate-on-first-call technique is easy to write. Avoid offering the session ticket extension if we know we don't have a key. For one thing it will cause us to avoid using stateful sessions, but additionally OpenSSL 1.0.1 is very intolerant of empty NewSessionTicket messages so definitely worth avoiding when we can.
* Include the curves and sig algos list in a session resumption clientlloyd2012-03-231-0/+1
| | | | | | | | | | | | | | hello. Also include a full list of ciphersuites, ensuring that our original session ciphersuite is in the list regardless of policy (maybe it would be better to just not resume in that case, though?). Otherwise, if the server doesn't remember our session (or the session ticket key), it might not be capable of negotiating using the single ciphersuite we sent due to lack of information (allowed curves was a particular issue here). Including the full ciphersuite list also allows for rengotiating the ciphersuite if, for instance, the session can't be resumed because the server used to have an RSA cert but has since replaced it with an ECDSA cert.
* Server side handling of session tickets, though currently with alloyd2012-03-221-3/+9
| | | | hard-coded key.
* Basic protocol message flow for session ticketslloyd2012-03-201-12/+10
|
* Various merge fixups.lloyd2012-03-161-4/+4
| | | | | Use AES-256 so we don't encrypt session tickets with a weaker algo than the ciphersuites.
* propagate from branch 'net.randombit.botan.tls-state-machine' (head ↵lloyd2012-03-161-101/+126
|\ | | | | | | | | | | c24b5d6b012131b177d38bddb8b06d73f81f70c4) to branch 'net.randombit.botan.tls-session-ticket' (head 9977d4c118e1ac26425cef676ebf26cd5b2a470e)
| * Add SecureQueue::emptylloyd2012-03-071-0/+20
| | | | | | | | | | | | Hide the handshake reader behind a function. Add pieces for DTLS hello verify request message
| * Add an abstraction for reading handshake messages (as DTLS handles itlloyd2012-03-051-4/+4
| | | | | | | | | | | | | | | | quite differently). Avoid using a queue for reading certificates. Hide the version code in the handshake state with a getter and setter.
| * Move the handshake serialization code to Record_Writerlloyd2012-03-031-3/+3
| |
| * Server side PSKlloyd2012-01-271-6/+5
| |
| * Somewhat cleaner PSK handlinglloyd2012-01-271-3/+4
| |
| * Server side PSK kexlloyd2012-01-271-2/+3
| |
| * Add client-side support for PSK kex. Tested against OpenSSL.lloyd2012-01-271-0/+4
| |
| * Move all key exchange mechanism code (eg DH/ECDH/SRP) out of thelloyd2012-01-251-3/+9
| | | | | | | | | | server handshake flow and into the server and client key exchange message types. It already was hidden from the client handshake code.
| * s/tls_suites/tls_ciphersuite/lloyd2012-01-241-1/+1
| |
| * We can now actually handle multiple certificate types in the serverlloyd2012-01-241-2/+4
| | | | | | | | | | and will choose one depending on which ciphersuites the client offered.
| * Remove Certificate_Type enumlloyd2012-01-241-2/+2
| |
| * Send the supported elliptic curves extension. Instead of hardcodinglloyd2012-01-241-2/+3
| | | | | | | | | | | | | | the values let policy specify them. Also choose an ECC curve for server kex from the client hello. Choice is via policy, default implementation is to choose the first curve the client supports out of the server's preference list.
| * Get the list of supported ECC curves out of the client hello, andlloyd2012-01-241-0/+3
| | | | | | | | | | avoid negotiating an ECDH key exchange if the client didn't send any curves that we know about.
| * Working ECDH key exchange. Only tested on client side but seems goodlloyd2012-01-241-2/+1
| | | | | | | | | | | | | | there. Only named curves supported, likely won't ever support explicit curves cause that's just asking for problems.
| * Don't assume the server key exchange consists of a series of BigInts.lloyd2012-01-241-3/+2
| | | | | | | | | | | | 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).
| * Make the version number a proper class, makes many things much easierlloyd2012-01-231-12/+12
| | | | | | | | for such a minor change.
| * Since this branch is hugely API breaking already, go ahead and putlloyd2012-01-231-21/+25
| | | | | | | | | | everything into a new namespace (Botan::TLS), removing the TLS_ prefixes on everything.
| * Remove the key() method on server key exchange - instead leave it tolloyd2012-01-231-1/+2
| | | | | | | | | | the client key exchange object to interpret the message on the basis of the chosen ciphersuite.
| * Have the client key exchange examine the server key exchange messagelloyd2012-01-231-5/+3
| | | | | | | | | | | | | | directly (if it was sent), so that the client implementation doesn't have to know what key exchange mechanisms we actually support. Return a value in ECC curves extension serialization method.
| * When generating a signature in TLS 1.2, respect the request of thelloyd2012-01-201-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * Instead of using a hardcoded value for signature_algothms, go withlloyd2012-01-201-1/+3
| | | | | | | | | | | | | | | | policy. Only functional change here from before is we now send DSA with SHA-2. This is fine, OpenSSL does it as well and while the spec says to wait until NIST comes up with a way to prevent hash impersonation, it doesn't really make sense to avoid possible hash substitution attacks by using the weakest available hash...
| * TLS_Ciphersuite_Algos was just a strange level of indirection betweenlloyd2012-01-201-10/+10
| | | | | | | | | | | | | | | | 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
| * Basic processing for signature_algorithms extension in client hellolloyd2012-01-201-0/+2
| |
| * Initialize values once in constructor instead of in each branchlloyd2012-01-201-7/+1
| |
| * Many fixes for TLS 1.2 though some things in particular client authlloyd2012-01-201-6/+8
| | | | | | | | | | | | remain broken. New interface for querying the TLS extensions, much cleaner.
| * Various and sundry bug fixeslloyd2012-01-191-0/+2
| |
| * Kinda maybe working TLS 1.2 for clients. Not well tested at all, but alloyd2012-01-191-1/+7
| | | | | | | | | | | | | | | | 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).
| * Remove Handshake_Message::deserialize which was an unnecessary hook.lloyd2012-01-191-20/+10
| | | | | | | | | | | | 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.
| * I'm not sure if I like this asthetically, but passing around thelloyd2012-01-191-29/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * Support SSLv3 client auth on the client side.lloyd2012-01-191-0/+2
| | | | | | | | | | | | Add getters for major and minor protocoll version on TLS_Session. Add Certificate_Type code points for ECC certs.
* | Build fixeslloyd2012-01-111-2/+6
| |
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 16:54:36 +0000