On Sun, May 17, 2009 at 8:22 PM, João Távora <joaotav...@gmail.com> wrote: > Maybe I didn't really fully explain myself, the problem is not really > ensuring secrecy and integrity, it's ensuring delivery. [...] > In this case the attacker would have tampered with the delivery assurance of > TCP but none of the sides would be aware of that.
TL;DR: replay attacks and other TCP/IP/lower network protocol layer tampering will be detected by the SSL layer, resulting in aborted communications. You cannot have guaranteed delivery; close approximation thereof requires additional application level protocol. You /can/ attack SSL through corrupting the trust in the PKI of the communicating nodes, which is an attack mode [intentionally] outside the scope of the SSL design. A few points here: your question seems to really be two questions rolled into one: 1) do I have guaranteed delivery (if so, why, and if not, how do I get it / why isn't it)? 2) what impact does SSL have on #1, especially with regards to MITM attack scenarios? Quite a bit has been covered in the answers so far, but there's still some material left. To get a better understanding, the division into those two questions is necessary. First things first: ad #1: as already hinted at in another reply, SSL doesn't depend on TCP (at least not at a level where single TCP messages are important individuals). That is because SSL is in principe a secure communication layer which assumes to be stacked on top of a 'stream protocol' (e.g. TCP). At interface level, both to the lower level in the network stack and the next upper level of the network stack (application layer, almost always) SSL acts as a stream protocol. Yes, even a 'stream protocol' works by sending messages, and that may be a bit confusing at times. Considering the 'guaranteed delivery' words in your text, IIRC (it's been a while) there is only one (generic) operating system out there which comes with a **guaranteed** [message] delivery protocol included, and that would be VMS. If my brain hasn't fissured beyond recovery, this is done through a particular $QIO mode. I'll get to that in a second. Today, usually you have IP network stacks, but keep in mind that PPP and others are not IP, yet the dichotomy you see in IP exists with all other network stacks as well: a) there's UDP, which is 'best effort' _message_ based transport. That means individual messages are important as individuals to the protocol-using layer above it as UDP will deliver messages, individually. They may be fragmented along the way, they even might be duplicated and the order in which they arrive is never guaranteed. Hence, UDP is a message-based protocol, which only offer the most basic of data transport: best effort delivery. Without any guarantees about in-order arrival, fragmentation, or duplication. If your next layer in the network stack doesn't accept this, it has to put countermeasures into place to prevent these 'artifacts' from happening. Countermeasures such as sequence fields in extra added message headers, etc. must be implemented by the UDP protocol _user_ if he needs things like that. That is why DTLS (over UDP) is a lot more work than SSL (over stream protocol, e.g. TCP) As such, UDP only uses a very simple header: to/from/data-length/data-checksum, nothing more. You may lose UDP message when they travel from sender to receiver, the messages can be fragmented, can arrive out of order, and in spurious cases may even arrive multiple times. b) next, there's TCP, which is /not/ a message-based protocol a la UDP but a stream protocol. That means that the TCP network layer takes care of ensuring 'in-order arrival' (aided by the larger header, which includes a sequence field). Consequently it also tries it best to 'fill the gaps' in the stream when those occur, while keeping this invisible to the next upper network layer (application layer, SSL, ...): the retransmission and data window parts of the TCP protocol take care of that. As such, TCP offers a continuous 'stream' of data to the next upper level in the network stack: TCP guarantees 'in order delivery' of data: you get the data, byte-for-byte in the same order as the sender fed it into it's own TCP network layer -- note that I do /not/ say 'messages' here: at the hardware layer you may see TCP/IP messages fly past carrying the same chunk of data over and over again until the sender 'got it' that the receiver actually received this data in good order. TCP also offers 'best effort' delivery, which some would call guaranteed delivery (which it isn't), in that is does /guarantee/ you'll get your data in order, non-duplicated, at the receiver's end. Mind you, there's no mention anywhere in this of messages, though this is accomplished through messages. That's because the next layer doesn't have to concern itself with the individual messages, hence TCP ACKs are irrelevant to the next layer. (And yes, there are very nasty ways to abuse TCP into becoming a sort-of message-based protocol, but that is WAY out of scope and is (1) very OS dependent, and (2) is essentially riding on the /side-effects/ of the inner workings of the TCP network layer. telnet can, philosophically speaking, be considered as messaging over a TCP stream, but I'll leave it at that because SSL certainly was /not/ designed for that type of usage and very special things must be done at the SSL layer level to make it 'usable' in that way. But I digress.) Note also that TCP does however /not/ guarantee delivery of everything you sent (which is 'guaranteed delivery' to the letter) because any [persisting] network failure will result in TCP connection loss and all you got at the receiver's is all you'll ever get as far as TCP is concerned: party's over, so to speak. If you /want/ the missing /remainder/ of that data stream, you'll need to implement your own mechanism on top of TCP to accomplish anything that would get close to 'guaranteed delivery'. E.g. by trying to establish a new connection with the sender and, through your application-level protocol, request the remainder of the data from the sender once the connection is established. Which brings us to the pinnacle in network communications: guaranteed delivery. c) the 'guaranteed delivery' I mentioned before: VMS offers this as a message-based protocol, but you can easily convert that into becoming a stream protocol by cutting the stream into messages and transfer them. How does it work? Well, TCP is connection-based, so once you loose the connection (for whatever reason: network failure or otherwise) you're done. VMS actually queues your messages (data chunks if you want to play stream over message protocol) and each message is potentially held in store indefinitely, until message from the receiver comes back that, yes, we got this one. This includes all the measures above: connection re-establishment upon failure to deliver (i.e. retry mechanisms at both message and node visibility levels), etc. It's been too long, but I seem to recall it also had options where you actually could request TCP-like behaviour: both in-order message reception and non-duplication. But my brain may be playing tricks on me there. What's all this nonsense about IP and other protocols to do with your question? You wonder about replay attacks, for one. For that, you need to be very clear on what such replay would actually accomplish. Same for other MITM attacks. And the preliminary answer is: TCP ACK message replay doesn't matter: SSL will detect this. IFF... Which brings us to your question #2: What does SSL do to prevent and/or detect attacks? Can it be harmed by certain attacks, i.e. will it allow certain malicious data to slip through? First, replay. As mentioned in previous email, there's the HMAC to the rescue. Which can be viewed as a very sophisticated data checksum. /NOT/ at TCP message level, but at /SSL/ message level, which, to TCP, is just a chunk of data in the entire data stream fed to it by the sender. A few scenarios: a) you replay data from B into the reception line of A and make it so that at TCP level, /that/ protocol won't notice you're duping stuff. This is done by incrementing the TCP sequence counters seemingly correctly in your attack messages and responding to ACK messages and everything else like you were B instead of the MITM you actually are. Thus manipulated, your messages == TCP stream data chunks will make it through the TCP layer into the SSL layer. Unfortunately for you, attacker, SSL keeps track of a sequence number of its own, which is part of the encrypted SSL messages. Let's assume you are a very lucky attacker and be sheer luck start replaying [modified] /TCP/ messages right at a /SSL/ message boundary: in that case, you were not able to adjust the SSL sequence numbers as they are encrypted and to edit those, you'd have to break the (symmetric) session cipher, which will be very hard to do if you don't have the session key (which was transmitted earlier during SSL connection setup). We'll get to that, let's assume you don't have that key, so breaking the encryption is a no-no (unless you apply tremendous brute-force effort), so SSL will catch you with your pants down as SSL sequence numbers will seem to repeat, which is a sure sign of tampering and thus, poof! tamper alert! and the SSL connection is shut down, while your data will /not/ make it through the SSL layer to the application layer. b) same as (a) but you do a 'simple' replay, i.e. no editting of your TCP headers. Too bad, but TCP will notice that your messages provide data that was already correctly received, so your messages are silently discarded in the TCP layer. End of story. c) you're smart, you don't so much replay as inject your own evil data instead of the honest material sent by B in such a way that A only gets to see your stuff. As you know how TCP works, SSL will receive your data as part of the incoming encrypted stream and this time, it's a 'you lose' again, due to you not having the key to encrypt your data in a correct fashion, so it's tamper alert and connection shutdown. By the way: your efforts are caught by that HMAC as that is the checksum which includes the session key and you fail to provide a proper checksum. Unless you have the session key... a-c) assume you don't have the session key, which is transmitted by the SSL protocol at connection setup (while 'renegotiation' can replace the session key with a fresh one along the way, which is a good thing to have when you are transmitting lots of data over a single connection: that way, any eavesdropper will only ever be able to collect a limited amount of data for any given session key, which makes it bloody hard to 'infer' the session key from the encrypted data.). Since the session key is transmitted, we should be able to get our grubby little hands on that one, right? That's where it becomes really interesting, because that's what public key crypto was created for: to prevent you from grabbing this. It takes a lot of math, but the crux is that at connection setup time, SSL uses public key cryptography (RSA, DSA, ...) to transmit a few items that are really really valuable. One of these is the (symmetric cipher) session key to be used by sender and receiver: that's your key/cipher agreement right there. Public key crypto is designed to give you a bloody hard time to decrypt publicly available [encrypted] data while a single other individual (Mr. B) will be able to decrypt it anyhow. Since you only have access to the public keys of both messieurs A & B, you won't be able to 'fake' them, i.e. pretend you are either of them. (Why comes in a sec.) As A sends that session key and other valuables out to 'assumed' party B, it also assumes all that good stuff is public knowledge at the moment it enters the network at his side, so he encrypts the whole kaboodle using B's /public/ key. To ensure B will be able to see /he/ (A) sent this, he'll also first 'sign' the valuables by encrypting it using his own private key. Public key crypto says you can only decrypt with one key what was encrypted with the other key of a key pair. Since you were not able to enter A's or B's premises and break into their locker, you haven't got their private keys, so you cannot successfully decrypt the valuables: you don't have B's secret key. B does, so he can decrypt, and once done that, he can also check if it was A who sent him this, by decrypting again using A's public key: if it all checks out (insert another checksum here ;-) ) we've got connection established and set up. d) You, as MITM, can try to 'mimic' A and/or B. Since the public key crypto used is strong enough to hold you off, i.e. allow each of them discover your attempts at impersonation / data injection / data elimination / replay (there's also a timer aboard to prevent you from recording the whole conversation and replaying the conversation as-is at a later time, by the way -- that's attack #d ;-) ) e) But you /can/ try to subvert the whole scheme in one way: somehow A and B must 'trust' each others public keys, before they can trust anything they send or receive to/from one another. Certificates are important here, as they encapsulate those public keys with all sorts of 'trust' in the form of additional signatures: the certificate chain. In the end it comes down to this: if you can subvert that certificate chain, i.e. can make B believe you are A as you are saying you are A while B accepts your 'proof' (i.e. the signature of the one vouching for you (your CA), directly or indirectly (= a CA who mistakenly vouches for one of your buddies who's acting as an evil CA for you), you have a way to put yourself between A and B if you can make A believe you're B as well. That would mean you'd meed to do much more than just sit in the middle as a non-transparant proxy. You may try to 'crack' the communications as they are (and many people have tried, which resulted in the improvement of the protocol over time: SSLv2 --> SSLv3, etc.), but from the above two things should be very clear: you will need brute force key cracking power to successfully insert yourself into running communications. That's what ciphers and increasing cipher key sizes are making harder for you as the years go by and your equipment improves as well. Replay schemes have been tested and tried a lot already and there are several quite interesting ones among them, but replaying TCP messages doesn't cut it. There are a few timing-based attacks that /may/, under certain conditions, lower your minimum required effort from brute force to a little less than brute force in your effort to infer the session key, but those are taken care of as the software is being improved over time. Given the above, what can an attacker accomplish? All tampering leads to connection disruption, so an attacker will be able to, ultimately, prevent A an B from talking to each other. Just jack some random data into their message stream and they'll abort. Anything more will just result in the same: connection shutdown. You can [try to] impersonate nodes by making the others out there mistakenly trust your forged certificate instead. This is outside the scope of SSL itself as this concerns PKI and only that. SSL depends on that and assumes communicating parties have their PKI operating securely. SSL has to assume /something/ as it needs some 'trust' to start everything rolling. Guaranteed delivery of data? The above should've made it abundantly clear this is not to be had: evil me can disrupt your communications and your application layer will need to provide ways to cope with that: SSL in this sense does not look beyond the single connection. You'll need VMS-like retry/retransmit approaches or other measures to ensure delivery and even then (as with those message queues in VMS) you may have data waiting indefinitely for a node to re-appear on the net -- when a node dies and is never reachable again, you cannot deliver anyway. When evil me sits in your transmission line, I'll be able to 'censor' (= disrupt) anything you do. Disruption is all I'll be able to do, but it will force you to find ways to go around me. Which would take the challenge to the level of 'how to communicate while living in a non-cooperating system', which is a whole another ballgame and way, way out of scope. Hence within a single SSL connection there can only be 'best effort' delivery, which can (and does) only /guarantee/ 'in order' and 'non-duplicated' data reception with 'no gaps' in the data received /so far/. Upper layer protocol will need to be added on top of this if you require anything resembling guaranteed delivery (or the next approximation thereof: explicit reception acknowledgement by the receiving end node). HTH -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
