aboutsummaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* | Split hello.cpp into c_hello.cpp and s_hello.cpplloyd2012-01-048-223/+271
| | | | | | | | | | | | Add support for NPN on the server side. Server is initialized with the list of protocols it wants to offer, once the handshake completes the client requested protocol is available via a getter.
* | Add support for next protocol negotiation. Client only currently;lloyd2012-01-0412-104/+362
| | | | | | | | tested with google.com:443
* | Fix unused param warnings. Comments in headerlloyd2012-01-032-25/+32
| |
* | If the handshake_fn returns false explicitly remove the session fromlloyd2012-01-032-0/+4
| | | | | | | | | | the cache. The current handshake will complete, but the session can not be resumed later.
* | Assume handshake_fn existslloyd2012-01-031-6/+1
| |
* | Make handshake completion function non-optional. Now returns a boollloyd2012-01-036-17/+16
| | | | | | | | specifying if the session should be saved to the session cache.
* | Add Credentials_Manager which is an interface to something that knowslloyd2012-01-0312-73/+202
| | | | | | | | | | what certs, keys, etc are available to the app. Needs polishing but it seems like it should be sound.
* | Code for NewSessionTicket handshake messagelloyd2012-01-031-0/+1
| |
* | Some basic infrastructure pieces for SRP (policy, etc)lloyd2011-12-316-23/+46
| |
* | Add support for client-side session resumptionlloyd2011-12-3110-101/+228
| |
* | Better names on the session manager. Plausible client lookup support,lloyd2011-12-303-23/+57
| | | | | | | | untested though.
* | Rename the session type to 'TLS_Session'. Split the manager out intolloyd2011-12-3013-164/+215
| | | | | | | | its own file. Rename tls_state to tls_handshake_state.
* | Add a function for getting the version number of an active connection.lloyd2011-12-3016-39/+85
| | | | | | | | | | | | | | | | 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.
* | Add support for the maximum fragment length extension. No hooks for itlloyd2011-12-309-141/+288
| | | | | | | | | | | | | | on the client side at the moment. Tested with gnutls-cli --recordsize. Save the fragment size and the secure renegotiation flags in the session state.
* | Prevent ping-ponging of close alerts by tracking both if a handshakelloyd2011-12-304-18/+31
| | | | | | | | | | has been completed and if the connection has been definitely closed by a fatal alert or a close notify.
* | Full support for renegotiation including RFC 5746 extensions forlloyd2011-12-308-42/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | client and server. Server side can handle SCSV values as well, client always sends the extension instead. Handle an empty SNI extension coming back from the server - this is used to indicate that it understood the name. Also add better checking for extensions by passing in what the supposed size of the extension is. Only send the secure negotiation extension in the server hello if the client indicated support for it.
* | Server side handling of the secure renegotiation extension.lloyd2011-12-303-2/+26
| |
* | Many renegotiation fixes. Add support for the secure renegotiationlloyd2011-12-3013-36/+209
| | | | | | | | | | extension (client side only at the moment). Add an interface that allows applications to request renegotiation.
* | Reset the sequence numbers when we activate a connection state. Thislloyd2011-12-302-0/+9
| | | | | | | | meant up until this point, renegotiation never worked. :(
* | About half an implementation of RFC 5746lloyd2011-12-2910-68/+158
| |
* | Add support for sending server name indicator in client hellolloyd2011-12-2911-70/+379
| | | | | | | | | | | | | | | | Add support for sending and reading the SRP identifier extension. Add some helper classes for managing TLS extensions Add ciphersuite codes for SRP key exchange.
* | Clean up the ordering of constructor args to the various message typeslloyd2011-12-299-99/+108
| |
* | SSLv3 clients will send this as a warning if the server requests alloyd2011-12-291-0/+1
| | | | | | | | client cert and they don't have one.
* | Ref mozilla bug alsolloyd2011-12-291-2/+2
| |
* | Only insert small fragments for application records. Handshakes wouldlloyd2011-12-291-1/+1
| | | | | | | | | | | | only be affected if the attacker can modify the handshake messages, which seems fairly unlikely, and some implementations are known to be unhappy with fragmented handshakes.