aboutsummaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* When generating a signature in TLS 1.2, respect the request of thelloyd2012-01-208-57/+73
| | | | | | | | | | | | | 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.
* Report the length of the pre master secret. Who knows if when thislloyd2012-01-201-1/+2
| | | | | happens it'll be reproductible, etc, might as well have the information immediately.
* Missing a spacelloyd2012-01-201-1/+1
|
* Increase the max key length of HMAC to 512 bytes. Previously we wouldlloyd2012-01-202-2/+9
| | | | | | | | | | | | | | run into trouble in the TLS PRF with large pre-master secrets. This especially crops up in TLS 1.2 as there the entire pre master secret is fed to a single PRF (in earlier verions it is split in half). A limit of 512 bytes allows a DH group up to 4096 bits which seems good enough for now. Also catch Invalid_Key_Length in the TLS PRF and throw an exception that makes more sense - initially I was completely thrown off by the HMAC key length exception, and it took me a while to figure it out. Someone else looking at this the first time a server sends a 8192 bit DH group would be even more confused.
* A change to Finished in 687c3c7dccdd2f5e4825bdb60155c7bfba22339f brokelloyd2012-01-201-3/+5
| | | | | | | | | 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.
* Helps if you return the right typelloyd2012-01-201-1/+1
|
* Support lookup of the SSLv3 PRFlloyd2012-01-201-0/+5
|
* Ignore ECDH suites in replyinglloyd2012-01-201-0/+3
|
* Fix decoding of signature_algorithms if we say something we don't recognizelloyd2012-01-201-4/+4
|
* Strangely you can negotiate using only MD5 in TLS 1.2. Just ignore itlloyd2012-01-201-5/+2
| | | | entirely if we see it.
* Instead of using a hardcoded value for signature_algothms, go withlloyd2012-01-207-20/+32
| | | | | | | | 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...
* New policy methods. User provides lists of ciphers, hashes, etc theylloyd2012-01-205-144/+231
| | | | | | | | | | | | | would like to use, in order of preference. Client sorts list of known ciphersuites by those preferences and sends them. Server now picks the first client method it knows and that it can use (previously, it would choose the one it liked the best out of what the client sent). New policy callback returns list of CAs allowed for client auth. Don't send certificate request unless we have at least one CA we want signatures from. OpenSSL has a behavior (bug?) in TLS 1.2 mode such that it will reject a connection if a certificate request is sent without any names included.
* Convert to using a switch statement here. It's faster, and offerslloyd2012-01-201-83/+88
| | | | | better checking (for instance, the DHE/RSA/SEED ciphersuite was not there, instead the DHE/DSS/SEED ciphersuite value was being checked).
* If the client sent something > TLS 1.2, we sould respond as TLS 1.1lloyd2012-01-201-16/+10
| | | | | | | | instead of TLS 1.2. The server now will respect policy.pref_version - if the client sends a version later than that, we reply with our preferred version. Before we would always reply with the version offered by the client.
* Somewhat contorted, but fixes the issue with sending hash/sig ids withlloyd2012-01-205-18/+40
| | | | older versions.
* TLS_Ciphersuite_Algos was just a strange level of indirection betweenlloyd2012-01-2018-506/+254
| | | | | | | | 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-202-1/+35
|
* Initialize values once in constructor instead of in each branchlloyd2012-01-202-14/+13
|
* Many fixes for TLS 1.2 though some things in particular client authlloyd2012-01-2013-150/+251
| | | | | | remain broken. New interface for querying the TLS extensions, much cleaner.
* Various and sundry bug fixeslloyd2012-01-199-11/+31
|
* Add the AES/SHA-256 suites to the standard lists. Works under TLS 1.2lloyd2012-01-191-0/+13
| | | | | | with GnuTLS. Seemingly it will not negotiate them if it is under an earlier protocol version. Some reports indicate Opera's TLS will do so, and there doesn't seem any reason to prohibit it.
* Kinda maybe working TLS 1.2 for clients. Not well tested at all, but alloyd2012-01-1921-88/+172
| | | | | | | | 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-1910-153/+132
| | | | | | 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-1915-311/+219
| | | | | | | | | | | | | | | | | | 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.
* Fix RSA client cert verification for SSLv3lloyd2012-01-191-3/+14
|
* Support SSLv3 client auth on the client side.lloyd2012-01-196-15/+53
| | | | | | Add getters for major and minor protocoll version on TLS_Session. Add Certificate_Type code points for ECC certs.
* Also fix encodinglloyd2012-01-191-4/+5
|
* Fix decoding of certificate request messagelloyd2012-01-191-5/+14
|
* Read only support for signature_algorithms extension used in TLS 1.2lloyd2012-01-185-54/+239
|
* The leading zeros of a DH pre master secret are supposed to belloyd2012-01-181-2/+23
| | | | | | 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.
* Rename queue_for_sending just sendlloyd2012-01-162-4/+4
|
* Change TLS feature macro, major API changes. Start documentinglloyd2012-01-161-2/+2
|
* Kill stray charlloyd2012-01-101-1/+1
|
* If we send the close notify alert, don't reset the reader because thelloyd2012-01-084-20/+30
| | | | | | | | | | | | | | | | | | | | 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.
* In the reader preallocate the buffer that we'll store the computed MAClloyd2012-01-062-21/+22
| | | | | | | 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.
* The server would incorrectly send a server key exchange message when alloyd2012-01-067-90/+85
| | | | | | | | | | | | | | | | | | 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.
* Remove the version getter in TLS_Channel - caller should use thelloyd2012-01-065-61/+31
| | | | | handshake callback info instead. Clean up the buffer consumption code in the record reader.
* Cleanupslloyd2012-01-051-17/+10
|
* Make record reading faster (less copying, no queue at all), at thelloyd2012-01-053-73/+138
| | | | | | 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.
* If the maximum fragment extension was negotiated, enforce it. Alsolloyd2012-01-054-2/+32
| | | | | enforce the 2^14 byte plaintext limit in the reader (previously only the 2^14+2048 byte ciphertext size limit was enforced).
* propagate from branch 'net.randombit.botan' (head ↵lloyd2012-01-054-52/+143
|\ | | | | | | | | | | 423204c45c686bfba0058cdc65b40b5bdfae5fb8) to branch 'net.randombit.botan.tls-state-machine' (head 3eb85687ada277da96946fa38a8f6993977583f0)
| * Remove the autheticator generation from the SRP code as it's not usedlloyd2011-12-314-52/+143
| | | | | | | | | | by TLS (relies on the finished message check). Add a class for reading files created by GnuTLS's srptool.
| * A bad decrypt on a TLS 1.0/1.1 message would cause a mostly infinitelloyd2011-12-311-1/+6
| | | | | | | | | | loop (size_t overflow), likely causing a segfault. Not exploitable as far as I can tell, beyond the obvious crashing.
* | Less buffer movement in the record readerlloyd2012-01-043-73/+83
| |
* | Add a hook in TLS_Channel that is called when an alert is received.lloyd2012-01-046-2/+34
| | | | | | | | | | | | | | | | | | 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.
* | Have Record_Writer use a single persistent buffer for outboundlloyd2012-01-042-13/+15
| | | | | | | | traffic.
* | Compile fixlloyd2012-01-041-1/+1
| |
* | Remove the support for writing application data before the handshakelloyd2012-01-042-14/+3
| | | | | | | | | | completes. The client gets a callback when the handshake is complete so they can know exactly when it's OK to send.
* | As someone pointed out on the TLS list, NPN isn't really a negotiationlloyd2012-01-048-23/+23
| | | | | | | | per-se, it's a notification by the client. Rename accordingly.
* | The first 4 bytes of the client and server randoms are supposed to belloyd2012-01-043-4/+16
| | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 18:21:56 +0000