> On Sep 26, 2016, at 3:23 PM, BITS Security <[email protected]>
> wrote:
>
> That said, at least one of the sites you mentioned was known to have an APT
> inside their perimeter (Operation Aurora) for about a month and part of the
> tactics within that attack which was publicly reported was the use of "SSL"
> to mask C&C communications. That's the type of threat we are concerned about
> inside of the enterprise network and we need visibility (and flexibility
> appropriate to our network design and risk tolerance) to solve for these
> issues in way that protects people like the ones you mentioned.
I very much doubt that the APT C&C traffic went out of its way to use
RSA key exchange to make the traffic enterprise-friendly, or even if
it happened to use RSA key exchange that the private keys were available
to the victim site...
All that RSA key exchange gives you is the ability to use long-term
keys of servers you control to decrypt past traffic through that server
if the private keys are still (or for better or worse become) available.
There are other ways to accomplish this. For example, the server might
use session ticket keys that are stored centrally encrypted under a
suitable escrow key. If clients always enable session tickets, then
every handshake will result in the server returning a session ticket,
in which case the session can be later decrypted if the session ticket
keys are available.
There's no need to change to the TLS protocol to make such things
possible, it is sufficient to purchase server devices that in one
way or another record session master secrets for later recovery.
There will surely be vendors who'll be more than happy to be paid
to fulfill any business needs in this space.
Having worked in IT security in the financial services industry for
more than a couple of decades now, I am rather surprised and somewhat
appalled by this thread. I don't believe that the concerns raised
should in any way influence protocol design. Products that offer less
forward-secrecy than the protocol would otherwise deliver will be
available to those who control either or both end-points and need
to be able to be able to produce after-the-fact plaintext.
The good news about doing key escrow deliberately, rather than
as an unintended side-effect of RSA key exchange, is that it
can be both more reliable and more secure, since the escrow
private keys need not be the same as the server long-term
authentication keys, and are therefor less vulnerable.
RSA key exchange has a long history of problems, and it is time to
move on. We should not be overly attached to one particular way of
doing key escrow.
--
--
Viktor.
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
