Am 30.07.2014 um 16:14 schrieb Viktor Dukhovni: > On Wed, Jul 30, 2014 at 08:41:51AM +0200, BlueStar88 wrote: > >> Regardless how difficult it would be to develop a reliable solution for >> that, I keep thinking here and throw another idea, inspired by Tor and >> it's multilayer crypto: Is there a way, once a connection is established >> to the server, to establish another one downwards within that >> connection? > This would add nothing. The server, having no way to prevent MiTM > of the client in the first place, does not not know who the client > is supposed to be, and therefore cannot "connect back" to the "true" > client. Nor does the message envelope reveal the "true" client > system, since email (architectural feature not SMTP bug) is a > multi-hop store and forward protocol.
First, I still like to limit my proposal to MTA-MTA connections. As told before I propose to let the client connect to the server and let the server connect back using a new connection layer -within- that inbound connection. This have to be solved first. Having SPF information (secured by DNSSEC at best) you'll get aware (as server), who is authorized to connect. So you have a legitimate "reverse target" you could make ordinary certificate checks against. a) If there was a successful MitM attack in the first place, but the sending MTA (client) does not care, you'll get aware of that, by using your own checks against the client thereafter. b) If it was instead possible to build a "trusted" or "verified" outbound connection within that inbound one, you are fine, (because you've in fact reached "the true client"). This second outbounding inner connection behaves like an ordinary server connection, not regarding smtp, but regarding TLS and its common tool set for certificate checks. At the end you have a double layered TLS connection, outer layer initiated by the client, inner layer initiated by the server. Mutual checks are possible because of reliable information pulled from DNSSEC secured MX-RR (for the client-server direction) and DNSSEC secured SPF-RR (for the server-client direction) and finally the mutual fingerprints verified using DANE. This proposal depends on being able to build a reverse tunnel through the previously established connection. I don't know, if it is possible at all, but I can imagine it is. Software developers are in fact only limited by their fantasy. Well, at most. ;-P >> Like this we could add another layer of trust and MitM >> sensitivity covering the other direction using the same tools we already >> have (maybe using SPF to stick to a set of hosts to verify given client >> certificates against). > I'm afraid your desire for a solution is overwhelming your analytical > skills to assess the problem. Your best bet is to hope that the > folks with the requisite skills are not negligent in addressing > the issue to the extent possible. Maybe it's just an insufficient communication issue here. I'm not sure to express myself correctly. Furthermore your mind maybe still sticks too much on thinking about the classical use of client certificates as authentication factor only. >> Is there any possible support for that in the TLS >> protocol or would it be able to do on the application level (assuming >> both sides using postfix)? > Contrary to popular belief, in no application protocols (not just > SMTP) do TLS client certificates solve the MiTM problem when the > client fails to authenticate the server. Rather, what client Sure, we would have to touch the TLS protocol to "some" degree adding a reversed tunnel. That's the point you most likely don't want or are not able to. ;-) > certificates do is channel-bind the presented client credentials > (which may or may not be those of the "true" or "original" client), > so that the server can be sure that there is no MiTM between it > the holder of the presented private key and associated certificate. > That private key might belong to the attacker. Such channel-binding > is useful, but does not address the nation-state intercept problem > if the client fails to verify the server certificate. That was told several times now and I'm aware about that, guaranteed. But this show me, that my above assumption, that you still stick on client authentication/credentials as only thinkable use case and can not imagine, to use a kind of reverted TLS connection in a second stage doing the prementioned server-like check procedure the other way around by reaching an additional layer of integrity as result. > In SMTP, the added complication is that client certificates are > not required, and thus the easiest attack is to simply suppress > them, while also modifying the signalling (HELO name, ...) that > might lead a server to demand a private key from some clients > that are expected to have one. What are you doing at present, if a server does not qualify for the "verify" or "trusted" security level? You reject it, possibly. So, do you have to do this for all servers? No. Why not? There are tables to set which domains or mail host have to qualify for that security criteria and which not. The same way you could handle the proposed dual layer mode. There could be a whole bunch of Postfix servers supporting this and have this as only allowed connection option by that new security level. The others will go classic TLS mode or cleartext. > The problem has no solution, and cannot have a solution. The > responsibility for ensuring channel security falls on the client, > it knows who the server is supposed to be. Only when the server > is designed to admit a single authorized client and no others is > it possible for the server to block MiTM when the client does not > do so, and even then only when the MiTM is unwilling to simply > redirect the message away from its true destination (deliver > elsewhere or discard). With SMTP the MiTM might simply return a > "4XX" code after "." and then allow the retransmission to be > delivered normally. > > Bottom line, we're doing what's possible to protect SMTP and no > more. As far as I know STARTTLS was invented after SMTP was. It guarantees interoperability and a choice for the peer. The same would apply to above proposal. Such a dual layer mode could be chosen by the peer and you're done with interoperability issues. Just let two "yay-cool" Postfix nodes decide to use the new double layer TLS mode and leave the others doing their classic asymmetric one way secured thing until they catch up. Assuming a quite good market share of postfix, such extensions should be easily rolled-out in the field, reaching a fast adoption, which attracts others to follow. And what do we have against to invent a new protocol anyways? If something has "no solution" you just tell the world ends here. This is a quite conservative position and is not working against tomorrows weaknesses and adversaries. You'll get overtaken by someone else sooner or later... -- BlueStar88 (bluesta...@xenobite.eu)
signature.asc
Description: OpenPGP digital signature
