Hi Ralph,
I agree with you about middleboxes being necessary in some enterprise
cases (I know that others vehemently disagree). I wish the TLS WG was
receptive to improve the protocol by allowing such boxes to declare
themselves and participate actively in the protocol
(https://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01).
But the "right" way to deploy enterprise middleboxes is by provisioning
their cert into the employees' endpoints, instead of educating them to
click through security warnings.
Similarly, airport networks often contain such middleboxes, where the
user (who has no reason to trust them of course) is supposed to Just
Click Yes.
Thanks,
Yaron
On 10/14/2014 02:59 PM, Ralph Holz wrote:
Hi everyone,
I second Yaron on the first point: it seems a good idea to mention theft
& forensics - in fact, we already reference some of these in the PFS
section, so we may as well add a few sentences with overall applicability.
On the second point - I am not quite so sure we should call it an
attack. In my experience, there are quite a few companies that use these
boxes for entirely legitimate reasons - especially in the context of
industrial espionage. When employees are informed and consent to this
practice, I do not view it as particularly problematic. In fact, there
was a very interesting I-D a while ago that proposed to export the
session keys to the middle box automatically so it would not have to
break up the cryptographic X.509 link. It did not seem to get much
support, unfortunately. My own network measurements show a significant
number of certificates that can be identified as having been created by
such middle boxes, so they are common.
Ralph
On 14 October 2014 13:45, Yaron Sheffer <[email protected]
<mailto:[email protected]>> wrote:
Hi Kathleen,
I sort-of agree with the first point, and fully agree with the
second one.
I think that both theft of the private key and forensic
investigation of the endpoint are essentially out of the document's
scope. However, they do motivate an important decision we made in
the BCP: to mandate forward secrecy. With that in mind, they are
worth a mention.
I agree that a middlebox that inserts itself into the connection by
relying on badly designed UI, a problematic PKI architecture and
non-expert users is indeed a valid attack. Definitely worth a section.
Thanks,
Yaron
On 10/14/2014 12:19 AM, Kathleen Moriarty wrote:
Kathleen Moriarty has entered the following ballot position for
draft-ietf-uta-tls-attacks-04: Discuss
When responding, please keep the subject line intact and reply
to all
email addresses included in the To and CC lines. (Feel free to
cut this
introductory paragraph, however.)
Please refer to
http://www.ietf.org/iesg/__statement/discuss-criteria.__html
<http://www.ietf.org/iesg/statement/discuss-criteria.html>
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/__doc/draft-ietf-uta-tls-__attacks/
<http://datatracker.ietf.org/doc/draft-ietf-uta-tls-attacks/>
------------------------------__------------------------------__----------
DISCUSS:
------------------------------__------------------------------__----------
Thank you for your work on this draft! It looks great, but I do
have two
items I'd like to discuss and see if we can add text to address
these
concerns/attacks before switching to a yes.
1. I think it would be very helpful to include what techniques
are used
by forensic tools that enable access to decrypt TLS sessions and
how to
respond/prevent that access. I see you have certificate attacks
listed
in 2.7, which is what the common forensic tools leverage.
However, these
tools also require access to the private key, and it would be
helpful to
mention the importance of protecting the private key, preventing
exportability, etc..
In 2.7 I thin it would be helpful to explicitly state that
commonly used
forensic tools such as wireshark require access to the private
key as
well as use of RSA. Another option might be to add the
recommendation to
protect the private key in 2.13. If you can't export the key
(from an
implementation perspective), that could go a long way to helping to
reduce this method of exposure.
I've included a few links for additional information on the list
of tools
and explicit details of the attack used in case this is helpful.
Forensic tools that rely on a MiTM attack to decrypt TLS and
DTLS
session:
http://forensicswiki.org/wiki/__SSL_forensics
<http://forensicswiki.org/wiki/SSL_forensics>
Wireshark requires you have the key:
http://support.citrix.com/__article/CTX116557
<http://support.citrix.com/article/CTX116557>
Mitigations are to protect the private key and to not use RSA:
http://wirewatcher.wordpress.__com/2010/07/20/decrypting-ssl-__traffic-with-wireshark-and-__ways-to-prevent-it/
<http://wirewatcher.wordpress.com/2010/07/20/decrypting-ssl-traffic-with-wireshark-and-ways-to-prevent-it/>
http://wiki.wireshark.org/__DTLS?highlight=%28tls%29
<http://wiki.wireshark.org/DTLS?highlight=%28tls%29>
If you would like text suggestions, let me know and I'll help.
2. I realize this draft covers explicit attacks against TLS, however
since pervasive monitoring is considered an attack, it could be
helpful
for this draft also cover techniques used by middle boxes to
intercept
TLS streams (proxy firewalls, load balancers, etc.). Although
these are
more of 'attacks' on the user, than of TLS, it could be a short
addition
to have this documented.
The TLS session is intercepted, or in the case of a load balancer it
might be terminated, with a second TLS session initiated to the
destination allowing traffic to pass in the clear on the
middlebox. The
user is alerted and warned to accept an untrusted certificate in
this
process, and many do as a result of corporate restrictions (they
have no
choice if they want to go to that site).
Perhaps implementation recommendations could assist here to
improve the
warnings to the user, letting them know their traffic may be
passing in
the clear and they may not want to continue with their session.
Some may
chose to avoid certain transactions from the work place as a result.
If you have already discussed these items and decided they were
out of
scope, please let me know. I support this work and just wanted
to make
sure we covered all bases or put some out of scope. Thank you.
_________________________________________________
Uta mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/uta
<https://www.ietf.org/mailman/listinfo/uta>
_________________________________________________
Uta mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/uta
<https://www.ietf.org/mailman/listinfo/uta>
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
