[TLS] Fwd: New Version Notification for draft-fenter-tls-decryption-00.txt
All, I have just submitted a draft outlining enterprise use cases for out-of-band TLS decryption. Please review. Thanks Steve Fenter -- Forwarded message -- From: Date: Mon, Mar 5, 2018 at 1:05 PM Subject: New Version Notification for draft-fenter-tls-decryption-00.txt To: Steve Fenter A new version of I-D, draft-fenter-tls-decryption-00.txt has been successfully submitted by Steve Fenter and posted to the IETF repository. Name: draft-fenter-tls-decryption Revision: 00 Title: Why Enterprises Need Out-of-Band TLS Decryption Document date: 2018-03-05 Group: Individual Submission Pages: 21 URL:https://www.ietf.org/internet-drafts/draft-fenter-tls- decryption-00.txt Status: https://datatracker.ietf.org/doc/draft-fenter-tls- decryption/ Htmlized: https://tools.ietf.org/html/draft-fenter-tls-decryption-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-fenter-tls- decryption-00 Abstract: Some enterprises are heavily TLS encrypted within their own enterprise network boundaries. Many of these enterprises are also utilizing out-of-band TLS decryption in order to inspect their own traffic for purposes of troubleshooting, network security monitoring, and for other kinds of monitoring. These monitoring functions are mission critical, and cannot just be done without when TLS 1.3 (draft-ietf-tls-tls13-26) is released or when the RSA key exchange is someday deprecated from TLS 1.2 (RFC5246). This draft will outline the use cases for out-of-band TLS decryption, as well as alternative suggestions for monitoring and troubleshooting and the limitations of those alternatives. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)
To clarify for anyone who has confusion on the enterprise TLS visibility use case, I think enterprises need to be able to do out-of-band decryption anywhere in the network that they own. It would be reasonable to terminate TLS on the enterprise's Internet connection, both inbound TLS and outbound TLS, as well as on business to business connections. We could run standard TLS 1.3 on these external connections, and then run our modified TLS on the inside. We also have internal browsers as well as other internal clients going to internal TLS servers, and these need deep packet inspection as well. Terminating TLS on the internal WAN head-end is less attractive, because there are significant sites outside of the data center that need troubleshooting and network security monitoring. For example, a large metropolitan area may have many office buildings with thousands of users as well as local servers. There can also be thousands of branch-type offices. We don't want to be blind to these large areas of our enterprise network. I think "scoping the solution to the data center" is the wrong way to phrase this, but rather it should be scoping to the internal enterprise network, owned and operated by the enterprise. Also, while there are some enterprises who terminate TLS coming in from the Internet and then run clear text on the inside, there are others who run new TLS sessions internally. There is a need for packet decryption and inspection at many layers of this internal TLS network. Steve Fenter > On Mar 24, 2018, at 7:37 PM, Ion Larranaga Azcue wrote: > > I recognize I may lack context, because I have only seen Steve Fenter's > slides, but apart from it not reaching consensus, the scenario it presents > (user connecting to online banking service) seems to be visibility of > connections from the internet to internal servers. > > I think that not even visibility proponents agree between them, as sometimes > they seem to require "server-to-server" visibility within the data center > while periodically use cases appear (such as the one you mention) where > traffic to be decrypted goes from internet to the internal network (or even > viceversa). I'm starting to understand someone who some months ago said this > looked like playing "whack-a-mole". > > Besides, from what I understand from Steve Fenter's proposal (I may be wrong > because I have seen only the slides) , they seem to go for non-visible TLS > 1.3 connections from the client to the external layers of the network, and > visible TLS 1.3 connections within their internal network. This would match > the idea of "visibility only within the datacenter" but in my opinion it > requires a finalization of the external tunnel and creation of a new internal > one. At that point you obviously have the clear text and you could move your > monitor tasks to that point. > > So maybe it's because the presentation is obsolete or because I lack context > but... no, I don't think those specific slides are a valid example today. > > > De: TLS en nombre de Jim Reid > Enviado: sábado, 24 de marzo de 2018 16:56 > Para: Dan Brown > Cc: tls@ietf.org > Asunto: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it) > >> On 19 Mar 2018, at 15:18, Dan Brown wrote: >> >> PS: I never directly worked on enterprise security (usually, I just think >> about the math of basic crypto primitives), but I don't recall hearing about >> such a "visibility" feature in the enterprise security work of colleagues >> (whom I do _not_ speak for), e.g. one system used forward-secure ECMQV to >> establish a connection between smartphones and the enterprise network. > > Hearsay anecdote is not evidence. :-) > > There are use cases in enterprise networks, notably in banking and finance. > Some of these were presented to the TLS WG. [See Steve Fenter’s presentation > at IETF97.] However the WG did not reach consensus on adopting the relevant > drafts as work items. > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)
MITM as a solution doesn't scale for the needs of the enterprise. Packet decryption and inspection is needed at many locations within the data center: at many tiers of an application, within the virtual environment, and within the cloud environment, all of which may be TLS encrypted. Speaking as a troubleshooter, a problem can happen anywhere in the enterprise network, and there are thousands of locations where I need to be able to take a packet trace and decrypt it in order to find a slow or failing transaction. The biggest problem I see with the key escrow solutions being suggested is that decryption is in some cases taking place in real time, even though it's out of band. This is being done, for example, for security inspection, for fraud monitoring, and for application performance monitoring. TLS decryption appliances are going to be getting packets off of 100 gig links, and when the packet arrives the keys have to be there. At this speed there's not a lot of time for queuing packets and waiting for keys. If we are going to use exported ephemeral keys, I think placing them in the packet as in draft-rhrd is the only scalable way to accomplish this. In response to unwillingness to change, enterprises are doing things today that work and that solve our business problems. The alternative suggestions being made, like MITM and endpoint monitoring, don't solve our business problems. In response to how much time we have, it was recently stated on the list that NIST has published a draft that disallows all non-DH cipher suites, which includes TLS 1.2. TLS 1.2 with Diffie-Hellman only will be just as big of a problem for enterprises as TLS 1.3 is. I don't have a crystal ball, but I don't I think the RSA key exchange is going to last five years as has been suggested. And whenever RSA is deprecated, it takes a long time to implement a new solution in a large enterprise, so we have to be well out in front of the problem, Steve Fenter > On Mar 24, 2018, at 3:31 PM, Tony Arcieri wrote: > >> On Fri, Mar 23, 2018 at 11:26 PM, Alex C wrote: >> As I understand it (poorly!) the idea is exactly to have a single system on >> the network that monitors all traffic in cleartext. > > And more specifically: to be able to *passively* intercept traffic and allow > it to be decrypted by a central system. "Visibility" with an active MitM is a > solved problem: have the MitM appliance double as an on-the-fly CA and > install its root certificate in the trust stores of all the clients you > intend to MitM. > >> It's fundamentally impossible to prevent someone from copying all their >> traffic to another system in cleartext. If they're going to do it, they will. >> The functionality is exactly the same as what could be achieved by >> installing monitoring software on each endpoint, but the logistics are >> different since the monitoring is centralized. > > The response from "visibility" proponents is "endpoint agents are hard". > However, it seems like there is a simple solution to this problem which > should be compatible with their existing monitoring architectures and require > no changes to TLS: > > Instrument TLS servers and/or client libraries used by internal enterprise > applications with a little shim that extracts the session master secret, then > makes another TLS connection to a TLS session key escrow service, and goes > "here's the session master secret for a session between X.X.X.X and Y.Y.Y.Y > with nonce ...". It could even be encrypted-at-rest to a particular > public key in advance (which could correspond to e.g. an HSM-backed > decryption key). > > Enterprises could continue to passively collect TLS sessions in whatever > manner they already do, and decrypt traffic at will, it would just require > looking up the session key for a particular session in a key escrow database > rather than having a single key-to-the-kingdom. > > This approach requires no changes to TLS, no changes to how "visibility" > systems collect traffic, and should provide better security in that using > session master secrets better scope the authority conferred to the decryption > service than D-H keys which can grant authority to e.g. resume TLS sessions. > > The downsides are you have to instrument clients and/or servers and have the > decryption service maintain a key escrow database. > > However, "visibility" proponents seem unwilling to accept any changes to > anything they presently do today. This is coupled with a sort of artificial > emergency where they claim (or outright lie) that compliance with industry > standards will require them to ship TLS 1.3 everywhere tomorrow. There is a > tot
Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24
I'd like to echo Dale's sentiments on the error codes. I've done a fair amount of TLS handshake troubleshooting, and it's usually long and painful because the error codes are so vague. Another factor in debugging is that people troubleshooting TLS in the enterprise are typically not the same level of experts as those who are writing TLS code. The TLS working group folks seem to have their fingers in TLS every day and know it backwards and forwards, so debugging a problem is not so difficult for them. They can also read code to figure out what is going on. In contrast, I see a TLS handshake problem once every few months. The rest of the time I'm looking at HTTP, SQL, SMB, or whatever. So enterprise troubleshooters are not going to be as deep in their understanding of TLS by the nature of their jobs, and they need all the help they can get (like from descriptive error messages). The vague error messages are leading directly to more downtime, and this should be balanced with the other security needs. I'm not saying this needs to be fixed immediately, but it should be considered somewhere down the road. > On Mar 6, 2018, at 9:35 PM, wor...@ariadne.com (Dale R. Worley) wrote: > > Colm MacCárthaigh writes: >> On the specific suggestion of having more granular error codes, I think >> this is a dangerous direction to take lightly; there's at least one >> instance where granular TLS alert messages have directly led to security >> issues by acting as oracles that aided the attacker. >> >> There's a general conjecture that the more information that is provided to >> attackers, the more easily they can leverage into a compromise. Personally >> I believe that conjecture, and would actually prefer to see fewer signals, >> ideally as few as one big error code. There is a trade-off against >> debugability, but I've only seen a handful of people have the skills to >> debug low level TLS issues and it doesn't seem worth the risk. Others >> disagree, which is valid, but it's at least an area of reasonable >> contention. > > I believe I've heard that position stated before, and I give it > credibility. I retreat to the statement I made at the top of my review, > that I'm not experienced in security. OTOH, I've spent a lot of the > previous couple of decades debugging SIP call flows, so I've learned to > appreciate any aid to debuggability that exists. > > I'm tempted to consider this a classic case of conflicting requirements, > and ask if our cryptographic experience can help us square this circle. > > Dale > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] draft-green-tls-static-dh-in-tls13-01
Proxies in the Data Center There are a number of reasons that inline proxies are not a scalable solution for monitoring communications in enterprise environments. -- cost -- production risk -- latency Here are some specific examples of where the use of proxies for monitoring communications is not viable: Network Security Monitoring Network security monitoring is not just monitoring traffic that results from communications with customers and partners. All it takes is for one user to click on a phishing email and there is malware inside the enterprise. Once this happens, TLS becomes the enemy, because 30% of malware is TLS encrypted, and any TLS features intended to thwart payload inspection work against the enterprise. Malware does not always phone home out to the Internet on day 1 of infection. Sometimes it does reconnaissance and lateral movement for a long time. The longer this goes on undetected, the worse the situation becomes for the enterprise. Microsegmentation is an attempt to contain this movement, but if the malware is TLS encrypted it will go right through the firewalls. The answer to this problem is ubiquitous plain-text traffic inspection. The scale at which this is needed can't be accomplished by inline solutions (proxies). Traffic inspection is needed at the Internet, the Extranet, the mainframe, the WAN, DNS servers, email servers, wireless controllers, and a host of other locations. Traffic inspection is also needed in the virtual environment, where all the virtual tools necessary don't exist yet. My Seoul presentation documented 150 physical tap points feeding network security monitoring devices - and this footprint is growing. There are too many inspection points to replace with inline solutions. You simply cannot place a proxy between every system in the enterprise. One other crucial point to this discussion is that endpoint monitoring doesn't catch everything. The strategy of "Defense in Depth" says that the more layers of security infrastructure you have, the better your chances of blocking or identifying malware. Network security monitoring is catching lots of malware missed by endpoint inspection. Threat Detection and Incident Analysis Threat detection inside the enterprise is not just receiving IDS or endpoint monitoring alerts. Threat detection analysts need to track down the source of the infection, which could be anywhere within the enterprise, and the primary tool for doing this is packet capture with a decrypted payload. Because the source of the infection could be anywhere, we need ubiquitous packet capture and ubiquitous decryption capability. Again, inline solutions don't scale to the number of monitoring points needed for this level of visibility. No only does an out-of-band solution like static DH allow many more permanent monitoring points with simple network taps, it also allows enterprises to deal with gaps in visibility. If a needed flow is missing, we can set up span or mirror sessions, capture the packets, and decrypt them after the fact. This can't be done when relying only on inline proxies. Adding a new inline proxy is a multi-month or more project. In the midst of an active attack/infiltration every minute is crucial and network re-architecture is not an option. Troubleshooting Enterprises provide services through complex, multi-layer applications and backend infrastructure. Inevitably, there are bugs in these applications and the source of the problem must be found through troubleshooting. Network troubleshooters need to inspect the packet payload in order to find transactions on the wire in environments where there is extensive NAT and extensive encryption. Both of these are very common in enterprise networks, and encryption inside the data center is becoming more ubiquitous over time. NAT, by the way, is being used in large part not for IP address exhaustion, but to allow for multiple redundant paths. Complex applications can have hundreds of application and infrastructure nodes as well as many tiers, any of which could be the cause of a slowdown or failure. Often there are no log messages on any device giving a clue as to the source of a problem. Troubleshooters need to be able to take a packet trace at any layer of the infrastructure and decrypt the trace in order to find the transaction of interest. This tracing could be between physical devices, like between a firewall and load balancer, or it could be between VMs. Tracing in the virtual space could involve tracing between VMs on different blades of the same blade chassis or between VMs on the same ESX host. Since the root cause of a problem can be anywhere in an enterprise, this translates into thousands of locations in a large enterprise where troubleshooters may need to take a trace, decrypt it, and locate a transaction. Inline proxy solutions add cost, production risk, and latency at every la
Re: [TLS] draft-green-tls-static-dh-in-tls13-01
> On Jul 11, 2017, at 2:15 PM, Stephen Farrell > wrote: > > > To add to Ted's clarification requests: > >> On 11/07/17 19:39, Steve Fenter wrote: >> Network security monitoring is not just monitoring traffic that >> results from communications with customers and partners. All it >> takes is for one user to click on a phishing email and there is >> malware inside the enterprise. Once this happens, TLS becomes the >> enemy, because 30% of malware is TLS encrypted, and any TLS features >> intended to thwart payload inspection work against the enterprise. > > I'd appreciate a citation for that 30% figure. 30% came from Cisco Systems at a recent Cisco Live conference. Their numbers indicated 10% in 2015 and 30% today > > And if you had one an estimate for how much malware does it's own > obfuscation or home-grown crypto in addition or instead of using TLS. > The reason to ask is that as soon as malware does that then you > are back to analysis based on ciphertext only. From descriptions > of advanced attack schemes, they do seem to do both when calling > home or exfiltrating data. In which case I think your argument > falls. I don't have any numbers for home-grown crypto. I would think the odds are better for the enterprise if they can decrypt and inspect whatever portion is TLS. > >> Malware does not always phone home out to the Internet on day 1 of >> infection. > > In what circumstance will malware phone home to a TLS server that > is playing your wiretap game? That seems utterly illogical but > maybe I'm missing a reason why someone's malware will use TLS to > talk to a server that is controlled by the victim network as part > of phoning home. Please clarify. Phone home would have to be caught by an inline solution on the way out the Internet. I was just suggesting that malware could be caught earlier in the process with multiple inspection points throughout the enterprise. > > S. > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
The main problem with not addressing the TLS visibility issue now is that no one knows when a vulnerability will be discovered in TLS 1.2 that forces enterprises to upgrade to TLS 1.3. We've had guarantees that TLS 1.2 and the RSA key exchange are going to be fine for 5 to 10 years, but nobody knows that, particularly in today's security environment. I've also learned that getting a solution in place through the IETF is a multi-year process, and then vendor adoption time has to be added on top of that. Enterprises don't want to be caught in a position where a vulnerability is forcing us to upgrade, and we are starting at ground zero on a multi-year process to restore TLS visibility. We have to get out in front of this problem so we're not caught unprepared. Sent from my iPad > On Oct 20, 2017, at 11:57 AM, "Salz, Rich" wrote: > > > >So it sounds like we are in agreement that continuing to use TLS 1.2 is > not a viable long term alternative. > > > Long-term is a subjective term, and using it can lead to misunderstandings. > > Based on current and previous actions around SSL and TLS versions, you can > use TLS 1.2 for at least five, likely at least 10, years. > > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
I know of a number of large enterprises in verticals including financial, health care, retail, and government, across multiple countries, who are using packet payload inspection within their data centers. Most of these enterprises are reluctant to step forward in a public forum and reveal their internal network structure and their internal security and monitoring practices. This gives the false impression that out of band decryption of TLS is not a big deal. It is in fact mission critical to a significant number of large enterprises. I have been saying to anyone who will listen that the IETF needs a private forum for enterprises, to enable them to come forward and discuss their real requirements. Without this input the IETF is trying to architect and engineer solutions without knowing the complete set of requirements, at least on the enterprise side. This results in sub-optimal design decisions (from an enterprise perspective), which in this case will break mission critical enterprise monitoring and troubleshooting systems. We've already experienced what a rollout of TLS 1.3 will be like, at more than one enterprise, when certain vendors decided to move Diffie Hellman ciphers to the top of their priority list on a code upgrade. This caused severity one outages of critical monitoring systems. This means that critical applications depend on these monitoring systems, and if the monitoring system is down the application is completely down. This is not the outcome we want when TLS 1.3 is rolled out, but it is what we are headed for. Enterprise monitoring should be tested as part of the operational TLS 1.3 testing before TLS 1.3 is approved as a standard, and TLS 1.3 should not be approved if enterprise monitoring breaks. The only other option being presented to enterprises is that we continue to run on a TLS spec that is nine years old, and then continue running it until it is 14 to 19 years old. It makes no sense to me to put out a TLS 1.3 standard, but say that enterprises cannot upgrade to it. > On Oct 19, 2017, at 5:37 PM, Christian Huitema wrote: > >> On 10/19/2017 3:30 PM, Darin Pettis wrote: >> >> The amount of people currently voicing concern is likely small for two >> reasons. One is that everything is public and many of the "lurkers" >> are hesitant to voice their concerns. The second reason is that so >> many don't know that visibility will be an issue. They will either >> discover this as they migrate to TLS 1.3 or as they start to encrypt >> within their data center. There is work to rapidly raise that >> awareness through roundtables, conferences and other venues. > > Might it be because many of these enterprises and data centers do not in > fact see encryption as a problem? Maybe they have found ways to manage > their applications and servers without breaking TLS... > > -- > Christian Huitema > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
