On 8/19/14, Florian Westphal <[email protected]> wrote: > Jacob Appelbaum <[email protected]> wrote: >> No. I want to protect my TLS service from implementation exploitation. >> You cannot probe my TLS service for the next heartbleed without a >> shared secret. > > So you won't accept e.g. smtp STARTTLS on your mail server?
That is likely a public service that is never going to be restricted with TCP Stealth. > > Also, once this becomes widespread, people will add > --probe-all-isns switch to their port scanners.... > That sounds fantastic - it suggests that a person is willing to send 2^32 packets to a single port. That will stick out like a sore thumb and of course, a system can detect this probing and take reasonable precautions. > It looks to me like this (I apologize In advance if this seems > offensive): > > Q: - I want to run $service, but I don't want anyone to see it! > A: - don't run it. That isn't an option. > > Q: - But I need to access the service sometimes from random locations! > A: - protect it with a password/some other form of secret. > That is exactly what is done here - we protect it with "some other form of secret." > Q: - But then its visible to port scanners! > A: - So what? Defense in depth - we don't need to run faster than the bear, only faster than everyone else. :) > > Q: - But it allows people who have detected service presence > to try running exploits against it! > A: - If you really care, tunnel via ssh perhaps? Using a VPN or something like a VPN is one option, yes. When that edge software has issues, it would be nice to ensure that a casual attacker will not even discover this software is running. > > Q: But I really really want to hide the presence of all services, > i.e. all tcp ports should appear to be closed > > A1: - There are portknock schemes to add obfuscation if you really want > this. > That is exactly what TCP Stealth aims to standardize. > Q: - But I cannot use portknocking because....? > A: - ? > > I tried to find explanation in draft-kirsch-ietf-tcp-stealth-00, > but did not find any. It talks about "pitfalls" of applications > trying to "reimplement tcp in user space". Perhaps there > should be a paragraph as to why ra > ...? > But even assuming that there is a need for portknocking and/or > TCP Stealth: > > - How does this relate to TCP-AO? > (The draft mentions tcp md5sig only, then disregards it as it > doesn't work in NATted environments) > > [ I realize TCP AO has other issues esp. vs. the proposed stealth > scheme, especially wrt. complexity. Anything else? ] > > > Problems I see with the proposal (ignoring the TCP related issues > others pointed out and the "obscurity only" approach), > and a few questions: > > - What about timing? I.e. is response time different regarding > RST-from-closed-port vs. RST-from-stealth port? This will vary by implementation and configuration. At the moment, I think that it is minimal over the internet but I wouldn't be surprised if there was a detectable jitter. I defer to Christian about specifics on this measurement though. Perhaps we can put up a service as a demo? :) > - e.g., are hosts required to perform authentication even for > SYN-to-closed-port, etc? > > - Your adversary may be able to do full passive monitoring of > all network traffic (also compare "replay" above), so whats the purpose > of "avoiding" active scans? > Exactly the purpose - we wish to avoid active scans. The GCHQ/NSA/CSEC do active scans when their full passive monitoring isn't enough. This hampers that angle of information gathering. It also ensures that even if they are monitoring with a passive/active tap - we can authenticate the first bytes of a secure protocol setup. This is good news - it means that even a sniffer can't wait for a sysadmin to ssh into the server and then hijack the session. > - Key Propagation (either your group is very very small, or I can > probably find the secret-secret-word via a web search...) The first is certain for many services, the second assumes a totally public service. There is no reason that the second must be true, even if the first assertion is correct. > > - Seems most services cannot use it since they have to accept > connections from (almost) anyone Huh? > > In fact, this is one of the main problems that I see with the proposal; > its use seems severely limited; up to the point where its unusable in > practice. > > Perhaps it would help to show specific usage examples > of how this would be deployed/where this is usable? I think gnunet.org is a good example of where it is currently deployed. > >> > Another objection: the mechanism help only for a small fraction of use >> > cases. Especially when the server communicate with one or a few >> > clients where the "shared secret" is no problem. But especially in >> > these setups TLS client certificates could be used without any >> > problems. >> > >> >> What happens in your example when there is exploitable code in the >> client certificate parsing code? > > "What happens in your example when there is exploitable code in the > payload protection verification?" > > [ Its rhetoric question. I am aware of complexity difference. The point > is, do your really think its worth to add yet another layer -- which can > have issues both in the specification and the implementation -- rather than > e.g. slim down/fix security transport protocol specs and implementations? ] > > Else, I guess I could argue that running your service via SCTP is "more > secure" since its "less likely to be found in scan..." > There is specific cryptographic complexity in TCP Stealth and that is not the case with SCTP in your example. All the best, Jacob _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
