14 ms·

Industry Concerns about TLS 1.3

313 points by Kliment 10y ago

chetanahuja 10y ago
"...almost all of whom are running TLS internally and have significant, security-critical investments in out-of-band TLS decryption. Like many enterprises, financial institutions depend upon the ability to decrypt TLS traffic to implement data loss protection, intrusion detection and prevention, malware detection, packet capture and analysis, and DDoS mitigation. Unlike some other businesses, financial institutions also rely upon TLS traffic decryption to implement fraud monitoring and surveillance of supervised employees." And thus essentially defeating the entire purpose of TLS. Can you please help us continue doing this with the new version of TLS too. Thanks. Love. Big Banks.
- rincebrain 10y ago
  Only sometimes. The argument here could be whether you, as an individual working for an employer on employer-controlled hardware, have the right to communications that cannot be viewed by the employer at their discretion on those systems. Having that capability (undecryptable communication) on an exceptional basis (e.g. only a few sites or methods do it) might be grounds for blocking any instances of the protocol that negotiate that level at the border. Having every secure site do it would result in not being able to passively store and only decode the communications that, say, you have occasion to go inspect later for discovery reasons, and instead would require MITMing and downgrading all connections (and storing the traffic, at best, re-encrypted with a different key). (Note that I'm not voicing an opinion on the topic, just observing that there are legitimate reasons to desire this functionality from several perspectives, which do not necessarily imply wanting a backdoor in the protocol in the general case.)
  - PeterisP 10y ago
    From a technical standpoint, the desire of <bank> to monitor all communications of a stockbroker in an easy and effective manner and being able to decrypt historical captured is identical to the desire of <evil government> to do the same for their civil rights activists. From a protocol perspective, you can't distinguish it - any new protocol either makes monitoring harder for everyone or easier for everyone, without checking if your reason is good or bad. If we choose to make communications more private, then yes, the ability to monitor stuff will suffer even if someone has a legitimate and reasonable reason to need this ability. Too bad, we've made a choice that the security of the masses is more important than this. I acknowledge that this change will hurt the banks for the reasons given above, but in this case hurting them is an unavoidable cost of helping most everyone else.
    - rincebrain 10y ago
      Sure, from a protocol perspective, arranging it so nobody, even the original owner, can decrypt the communication after the fact is beneficial, except that now, you end up with people downgrading such communications or storing the session secret keys, the latter probably by patching software crypto implementations where possible (since I doubt any of the major crypto implementations would agree to storing those keys even with an --i-am-a-developer-really-stop-bothering-me flag). I hope I'm wrong. I don't want to end up in a world where all enterprises actively MITM and negotiate down to non-PFS protocols to avoid this, or hack up the software stacks on their machines to circumvent this (with all the overhead that implies - echoes of "requires Internet Explorer 5" for how old some of this will probably get between updates). I just don't think that the people who make use of this functionality are going to let it go, no matter what it takes. (That's not to say it's not worth trying, to be clear - I just foresee it ending poorly for everyone except for private individuals, and possibly even them if ISPs start requiring you accept their MITM CA.)
madmax108 10y ago
>>> My view concerning your request: no. is probably the best response for the request. On a related note though, it's always amazing how on one hand Big Banking tries to show that it's in touch with the latest tech developments (Bitcoin Consortiums, RFID/NFC payments) etc. but on the other hand display a very shallow understanding of how secure systems should work.
- viraptor 10y ago
  I think that's a very biased way of looking at this request. They don't necessarily have a shallow understanding. They have a set of very strict rules they have to obey. If that means no privacy for the employees, then they have to implement no privacy for the employees. The reasoning of the author has been explained pretty well in my opinion. But that's completely orthogonal to the understanding how the secure systems work.
  - usgroup 10y ago
    Indeed, orthogonal. I think it's a denied attempt to connect cross-purposes. I.e. design for security with practicalities of implementation in a broader context. I notice some posts argue that we should aim for a pareto-optimum and accommodate the banks, but really this should require a broad representation for the rest of the subjects of TLS 1.3 to work out exactly what the pareto would look like. Given that they are 15 drafts in, it seems to me that there has been ample opportunity.
- rdtsc 10y ago
  I call it paper security or checklist security. Usually it is about implementing enough to check off a list of requirements from some document. Antivirus installed? Check (Nevermind it is a Linux box and AV loads a dubious proprietary driver in the kernel with a huge attack surface and remote exploit posibility because of how it does updates), such and such EAL-4 operating system intalled? Check, and so on ... So they tick all the boxes and in the end up with a worse off posture than if they just stayed with defaults for example.
  - 10y ago
pmarreck 10y ago
Well, that was kind of a burn. Was the argument by the bankers basically a complaint that retooling would be very expensive? and/or that employee surveillance would be more difficult? (yeah, I'm sure everyone is a fan of that!)
- brazzledazzle 10y ago
  mitm surveillance of employee traffic is basically a cornerstone of enterprise security since those networks are designed to be very squishy on the inside. Thankfully Google is turning the assumption that the perimeter needs to extend to your rather vulnerable clients on its head but that will be several years before it's productized enough that middle managers will be convinced to buy it by a VAR over a game of golf.
  - fulafel 10y ago
    Highly culture and jurisdiction dependent. Many places ban this with some narrow exceptions (defense sector etc) in law and/or binding labour org agreements.
  - ChoHag 10y ago
    That's basically putting the cart before the horse. Security is hard. Hard problems are easier when there are fewer of them. It's easier to build one big wall than lots of little ones. Surveillance of employees is a cornerstone of enterprise security because humans are inherently untrustworthy. One part of the solution to this problem is to define a distinction (using golf[+] of all things as an analogy) between the rough, the fairway and the green. Because defining a border between the rough and the course is easy, and untrustworthy humans aren't all that bad most of the time, the distinction between the fairway and the green easily becomes blurred. While employers may polish up the distinction between their workaday desktops and their locked-down servers they will never abandon the difference, and nor should they, between their systems and everyone else's systems. [+] You have my permission to use this analogy with your manglers.
    - brazzledazzle 10y ago
jrockway 10y ago
I don't understand why the banks need to change TLS 1.3 to spy on their employees. When I was working at a bank, there were literally no routes from the Intranet to the Internet. Everything went through a proxy that blocked 95% of the Internet. Had to run a proxy server on jrock.us in order to get anything done. (They just bought the list of sites to block, and jrock.us never ended up on it. Blacklisting, very good security technique...)
- notyourwork 10y ago
  Who doesn't love a game of wack-a-mole?
  - ChoHag 10y ago
    Why else is OP still employed?
- zigzigzag 10y ago
  The guy's rationale may be kind of dubious but it's clearly stated: there aren't any tools that do DPI on TLS 1.3 sessions right now.
  - jrockway 10y ago
    You don't need to do deep packet inspection when you just MITM all the traffic.
    - blazespin 10y ago
      Infrastructure upgrades are required. tls1.3 will be expensive
      - vacri 10y ago
        So let the CEOs have a year of $40M bonuses instead of $50M bonuses. A small price to pay for better security for the rest of us.
kbart 10y ago
"Like many enterprises, financial institutions depend upon the ability to decrypt TLS traffic to implement data loss protection, intrusion detection and prevention, malware detection, packet capture and analysis, and DDoS mitigation. Unlike some other businesses, financial institutions also rely upon TLS traffic decryption to implement fraud monitoring and surveillance of supervised employees." I'm at lost here. What's the point of having TLS if it can be easily decrypted? Why not to ditch it altogether then? All this argument sounds somewhat fishy, just because your practices rely on insecure behavior, it doesn't mean it shouldn't be fixed for the rest of us.
- viraptor 10y ago
  You still get the verification of the other side and still get the encryption on the wire, preventing external MitM. It's just TLS benefiting the company in general, not users separately. You do not want your outgoing traffic to partners and APIs to go out in plaintext. Basically the model changes from Alice <internet> Bob to Alice, Alice's employer <internet> Bob.
- xorgar831 10y ago
  They key phrase is "rely upon", meaning they went down a route of using a clever hack rather than formally designing a system to meet their goals. I wonder why SOCKs proxies, which every browser supports, wouldn't work for them.
  - viraptor 10y ago
    When you use a SOCKS proxy, your traffic is still encrypted from user to server. It wouldn't help them decrypt historic TLS sessions on request.
    - xorgar831 10y ago
      rather a regular http proxy that every browser supports And exactly as expected, they have a MSFT stack so they're wedged and think changing the spec is the right way to solve it. Sigh. > With TLS 1.2 we can ask the end user to take a Wireshark trace and then decrypt it with the RSA private key. With TLS 1.3 we will have to rely on the SSLKEYLOGFILE feature in Firefox and Chrome, so we want it to be available. Unfortunately, Microsoft does not allow this functionality, which is a problem in a TLS 1.3 only environment.
CDokolas 10y ago
Well, North Korea is not complaining about TLS 1.3, why would banks have to? Their proxy servers are already MITM platforms that meet their needs for security.
- askmike 10y ago
  Probably because Bank employees/customers use modern browsers/devices which will at some point drop support for anything but TLS 1.3. I don't think this will happen in North Korea.
deleted 10y ago
[deleted]
lexman0 10y ago
There are a lot of keyboard warriors in this thread. This guy puts forward a rational argument for big business. Unless you have extensive experience in this area, perhaps you shouldn't be so quick to judge "oh they are just spying on their users". The simple answer to this question is that if a way is not given for businesses to decrypt their own traffic that they generated and encrypted, they simply won't encrypt it. Take this example: A regulation says that all incoming traffic into a banking sector company must be scanned for potential vulnerabilities and exploits, and allows for "compensating controls". If the incoming traffic is unable to be decrypted at TLS1.3, it will simply be decrypted at the boarder of the business and routed internally unencrypted. This would be worse than copying the TLS1.2 traffic for out-of-band scanning. I'm not saying that this guy wasn't a little late by the party, but failing to recognise that big businesses have regulations you don't understand or even care about is a huge mistake that will make us all more insecure. After all, who doesn't have a bank account?
- 4ad 10y ago
  > After all, who doesn't have a bank account? But rules and regulations shield me and give me legal and financial aid for the stupid thing my bank might do.
  - lexman0 10y ago
    True enough. But those who steal your account information and use it to pose as you don't follow the rules and regulations.
    - 4ad 10y ago
      But the bank follows the regulations that tell it to give me all my money back, if there's some fraud. I don't have any money to lose if the bank does not implement security properly. Only the bank has to lose.
      - pdpi 10y ago
        They'll refund you after you've already lost the money, or the attacker might use the bank details as part of larger-scale identity theft that might come to leave you in hot water with law enforcement if he uses your identity to commit a crime. All that inconvenience is your own loss, and the bank paying damages for that doesn't really "fix it"
anonymousDan 10y ago
I don't quite get what they are currently doing. Is it that they have some kind of Internal mitm proxy that proxies every TLS session with external hosts, recording the conversation for later offline analysis? Why wouldn't they still be able to do that? Or are they just worried about their ability to intercept internal conversations? I'd be really interested to know what a typical bank security architecture looks like, does anyone have a reference for further reading perhaps?
- 4ad 10y ago
  They don't MITM, they record sessions and later decrypt out-of-band as needed. With TLS 1.3, they would need to MITM, which require infrastructure changes and potentially affects the performance. They are complaining TLS 1.3 forces them to do work they otherwise wouldn't have to do.
  - anonymousDan 10y ago
    But how doe they get access to the keys for the session without modifying the end hosts or MITM'ing the traffic?
    - 4ad 10y ago
      > without modifying the end hosts They have full control of the end hosts. That's why the group policy forces you to use Internet Explorer instead of letting you use Firefox.
      - anonymousDan 10y ago
        Hmm, but why can't they just then record the session keys as before even for forward secure TLS (presuming we are talking about clients inside the bank initiating TLS sessions to external parties)?
        ChoHag 10y ago
        Ah well they're banks you see and "doing things" requires spending money which they're rather averse to. Also never use the word just outside the context of law.
perlgeek 10y ago
Isn't it pretty much standard for such organizations to have decrypting and re-encrypting proxy, with their own CA that clients have to trust? If they do, I don't see how forward secrecy changes much, and they just have to tap the plain text from the proxy. If they don't, I'm seriously surprised.
- akvadrako 10y ago
  The original message does make dubious claims, but a little later in the thread, the real issue becomes clear. from https://mailarchive.ietf.org/arch/msg/tls/1n1tQSGKMBJKsmuCe-j-GPACvZw https://mailarchive.ietf.org/arch/msg/tls/1n1tQSGKMBJKsmuCe-... "With TLS 1.2 we can ask the end user to take a Wireshark trace and then decrypt it with the RSA private key. With TLS 1.3 we will have to rely on the SSLKEYLOGFILE feature in Firefox and Chrome, so we want it to be available. Unfortunately, Microsoft does not allow this functionality, which is a problem in a TLS 1.3 only environment." As I understand their argument, if you control the server (and hence private key and cipher suite) you can store the traffic without MITM and later decrypt it if needed. With forward secrecy, that isn't possible.
  - ghshephard 10y ago
    If you control the server, you can decrypt any time you want, because obviously if you were able to decrypt at one time, you can do so later.
    - akvadrako 10y ago
      That's the whole point of forward secrecy. For the one session you use a temporary key which can't be recovered later. You can only decrypt the stream if you store that key.
      - deleted 10y ago
        [deleted]
      - merb 10y ago
        well your proxy can just store everything in Plain Text? I mean if you really need to decrypt it later you already saved it somewhere, however you can just store the plain text since your proxy already has that?
heisenbit 10y ago
It may well be that from a business perspective a greater threat to banking is coming from insiders, failing systems and incompetence than from outsiders exploiting TLS weaknesses. To those wondering why banks are worried about their employees communication even internally keep in mind that there have been very expensive judgements related to banking employees conspiring to break legal or other regulatory rules. The alternative namely monitoring on the end points is hard to implement comprehensively and a lot more expensive. If (and that is a big iff) the banking use case really justifies a special and weaker transport protocol then maybe it should be upon the banks bear the whole cost of doing that. It would also clearly assign the responsibility when things may fail from a security perspective. Maybe the end point alternative looks then more attractive.
akvadrako 10y ago
A more readable link: https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr6P9SCQBqA https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr...
avar 10y ago
Here's the exchange, I found this hard to read without word-wrapping: > On 22 Sep 2016, at 20:27, BITS Security <BITSSecurity at fsroundtable.org> wrote: > > To: IETF TLS 1.3 Working Group Members > > My name is Andrew Kennedy and I work at BITS, the technology policy > division of the Financial Services Roundtable > (http://www.fsroundtable.org/bits). My organization represents > approximately 100 of the top 150 US-based financial services > companies including banks, insurance, consumer finance, and asset > management firms. > > I manage the Technology Cybersecurity Program, a CISO-driven forum > to investigate emerging technologies; integrate capabilities into > member operations; and advocate member, sector, cross-sector, and > private-public collaboration. > > While I am aware and on the whole supportive of the significant > contributions to internet security this important working group has > made in the last few years I recently learned of a proposed change > that would affect many of my organization's member institutions: the > deprecation of RSA key exchange. > > Deprecation of the RSA key exchange in TLS 1.3 will cause > significant problems for financial institutions, almost all of whom > are running TLS internally and have significant, security-critical > investments in out-of-band TLS decryption. > > Like many enterprises, financial institutions depend upon the > ability to decrypt TLS traffic to implement data loss protection, > intrusion detection and prevention, malware detection, packet > capture and analysis, and DDoS mitigation. Unlike some other > businesses, financial institutions also rely upon TLS traffic > decryption to implement fraud monitoring and surveillance of > supervised employees. The products which support these capabilities > will need to be replaced or substantially redesigned at significant > cost and loss of scalability to continue to support the > functionality financial institutions and their regulators require. > > The impact on supervision will be particularly severe. Financial > institutions are required by law to store communications of certain > employees (including broker/dealers) in a form that ensures that > they can be retrieved and read in case an investigation into > improper behavior is initiated. The regulations which require > retention of supervised employee communications initially focused on > physical and electronic mail, but now extend to many other forms of > communication including instant message, social media, and > collaboration applications. All of these communications channels > are protected using TLS. > > The impact on network diagnostics and troubleshooting will also be > serious. TLS decryption of network packet traces is required when > troubleshooting difficult problems in order to follow a transaction > through multiple layers of infrastructure and isolate the fault > domain. The pervasive visibility offered by out-of-band TLS > decryption can't be replaced by MITM infrastructure or by endpoint > diagnostics. The result of losing this TLS visibility will be > unacceptable outage times as support groups resort to guesswork on > difficult problems. > > Although TLS 1.3 has been designed to meet the evolving security > needs of the Internet, it is vital to recognize that TLS is also > being run extensively inside the firewall by private enterprises, > particularly those that are heavily regulated. Furthermore, as more > applications move off of the desktop and into web browsers and > mobile applications, dependence on TLS is increasing. > > Eventually, either security vulnerabilities in TLS 1.2, deprecation > of TLS 1.2 by major browser vendors, or changes to regulatory > standards will force these enterprises - including financial > institutions - to upgrade to TLS 1.3. It is vital to financial > institutions and to their customers and regulators that these > institutions be able to maintain both security and regulatory > compliance during and after the transition from TLS 1.2 to TLS 1.3. > > At the current time viable TLS 1.3-compliant solutions to problems > like DLP, NIDS/NIPS, PCAP, DDoS mitigation, malware detection, and > monitoring of regulated employee communications appear to be > immature or nonexistent. There are serious cost, scalability, and > security concerns with all of the currently proposed alternatives to > the existing out-of-band TLS decryption architecture: > > - End point monitoring: This technique does not replace the > pervasive network visibility that private enterprises will lose > without the RSA key exchange. Ensuring that every endpoint has a > monitoring agent installed and functioning at all times is vastly > more complex than ensuring that a network traffic inspection > appliance is present and functioning. In the case of monitoring > of supervised employee communications, moving the monitoring > function to the endpoint raises new security concerns focusing on > deliberate circumvention - because in the supervision use case > the threat vector is the possessor of the endpoint. > > - Exporting of ephemeral keys: This solution has scalability and > security problems on large, busy servers where it is not possible > to know ahead of time which session is going to be the important > one. > > - Man-in-the-middle: This solution adds significant latency, key > management complexity, and production risk at each of the needed > monitoring layers. > > Until the critical concerns surrounding enterprise security, > employee supervision, and network troubleshooting are addressed as > effectively as internet MITM and surveillance threats have been, we, > on behalf of our members, are asking the TLS 1.3 Working Group to > delay Last Call until a workable and scalable solution is identified > and vetted, and ultimately adopted into the standard by the TLS 1.3 > Working Group. > > Sincerely, > > Andrew Kennedy > Senior Program Manager, BITS The reply: To: BITS Security <BITSSecurity at fsroundtable.org> Subject: Re: [TLS] Industry Concerns about TLS 1.3 From: "Paterson, Kenny" <Kenny.Paterson at rhul.ac.uk> Date: Thu, 22 Sep 2016 19:14:25 +0000 [...] Hi Andrew, My view concerning your request: no. Rationale: We're trying to build a more secure internet. Meta-level comment: You're a bit late to the party. We're metaphorically speaking at the stage of emptying the ash trays and hunting for the not quite empty beer cans. More exactly, we are at draft 15 and RSA key transport disappeared from the spec about a dozen drafts ago. I know the banking industry is usually a bit slow off the mark, but this takes the biscuit. Cheers, Kenny
Nursie 10y ago
While they were very late to the party, this is important for some sectors. Not the reliance on specific tech (RSA) but being able to go back and decrypt their own traffic later, with appropriate keys. They need to routinely spy on some of their people,amd trace what happens to their money. Not sure why this is a problem. Their use-cases are different to (say) a user of Signal.
- askmike 10y ago
  > They need to routinely spy on some [..] people Unfortunately this is very far removed from the goals of the IETF, who is striving for a more secure internet.
knorker 10y ago
> Exporting of ephemeral keys: This solution has scalability and security problems on large, busy servers where it is not possible to know ahead of time which session is going to be the important one. I don't buy it. You can store entire sessions worth of data, but can't also optionally save metadata? Yes, I realise you may not want to store it for all connections, but if you don't want to have a "should I store" oracle inline with the connections, then do it async and skip writing it do disk/storage service once the answer comes back.
saurik 10y ago
Welcome to almost two weeks ago? Given how many people seem to be upvoting and commenting on this link, was everyone else on vacation for some holiday I don't celebrate when this came up multiple times before? https://news.ycombinator.com/item?id=12560284 https://news.ycombinator.com/item?id=12560284 https://news.ycombinator.com/item?id=12561004 https://news.ycombinator.com/item?id=12561004 https://news.ycombinator.com/item?id=12563481 https://news.ycombinator.com/item?id=12563481
- veeti 10y ago
  This had a much catchier, editorialized title earlier.
FuckOffNeemo 10y ago
Wouldn't this be solved by having multiple SSL offload reverse proxies at the points you want to decrypt traffic?
phkamp 10y ago
This is exactly the clash between governments (here financial regulation) and cyberlibertarians I wrote about earlier this year: http://queue.acm.org/detail.cfm?id=2904894 http://queue.acm.org/detail.cfm?id=2904894 What have we gained in security, if TLS1.3 is basically illegal to use for banks ? Who wins if browsers refuses to connect to web-banking which operates inside the boundaries of the law ?
- aseipp 10y ago
  But they're claiming it will require overhauling their infrastructure and cost money to do -- not that it's impossible to support, or that TLS 1.3 will "be illegal" if their demands are not met (this is just nonsense and 100% FUD on part of your comment, honestly -- and I say that as someone who thinks highly of your work). Furthermore there's no clear evidence TLS 1.2 will be deprecated anytime soon, so these people have years to sort out the details with their vendors to have replacements in-flight. Banks have money and connections. They'll survive this and evolve. In any case, they could have made their concerns available earlier to the standards body. Like, over two and a half years ago (RSA key exchange was removed in early 2014). This is hardly the fault of "cyberlibertarians" or whatever, this is just these people being out of touch. The alternative here would be that these guys get to butt into the standardization process and demand changes at the very last moment, after years of work, with no negative impacts or consequences for them -- for what is ultimately a small portion of the overall internet. Why would we want that? It completely undermines the authority of the IETF and the entire point of a standards process if "really important" people can just completely railroad it and demand changes on a whim with no consequences to themselves. Frankly, completely ignoring the actual content of the request, this alone is pretty bad behavior on their part. Why we should worsen the security of billions of people, and introduce complexity into a vital internet protocol, so that those dorks can have slightly higher profit margins -- I dunno. Designing a security protocol is hard enough. If they didn't want to pay attention to the conversation, and now want to cry their pockets will take a hit -- well, maybe they'll learn and be more proactive next time and save themselves some cash. > Who wins if browsers refuses to connect to web-banking which operates inside the boundaries of the law ? Nobody ever said TLS 1.3 would be illegal for banks, that browsers are going to immediately drop TLS 1.2 after this (both of these two being a requirement for your prediction to be true -- lol, and also completely asinine) making it refuse to connect to a "law abiding bank", or that moving to TLS 1.3 would be literally impossible for them forever and can't be solved. This is just complete FUD dude, c'mon. Unless you're actually interested in the answers to completely nonsense hypotheticals made up out of thin air, I guess...
stephen_g 10y ago
I think this request is pretty unreasonable, and anything that stops the ability to passively snooping on TLS is a great thing. I think there could be a security gain though in adding support for a better way to actively MITM TLS traffic though - in having a proper mechanism for filtering proxy firewalls. For some applications (say, school networks) it is OK to monitor and filter traffic, but the way it is done now is terrible for security. Usually this is by terminating the TLS at the proxy, scanning it, and then re-encrypting it with an certificate automatically generated and trusted by an internal CA (whose root certificate is installed on the machines). The huge problem is that now everyone has to trust all the root CAs installed on the firewall, instead of being able to decide which ones to trust themselves. The firewall has to also decide whether or not to trust self-signed certificates. Much better would be to be able to decrypt, re-encrypt with a certificate issued by a real CA, and then also send the original certificate along with the handshake. Then, the first time you visited a TLS site, it could pop up a big warning saying 'This traffic is intercepted by firewall.institution.edu, do you consent?' and have a little exclamation mark in the toolbar to always indicate that it's being intercepted. The browser would have to trust both the interception certificate (which encrypts between the firewall and the endpoint inside the internal network) as well as getting the original certificate and deciding whether to trust that (which you don't get now).
- deleted 10y ago
  [deleted]
- bchociej 10y ago
  I like your proposed (user-visible) solution quite a lot, this would be great. I predict certain folks would respond to this by trapping themselves in the indefensible position of "but if they know we're intercepting them, how will we catch them being bad?!?!"
- Tharkun 10y ago
  Why do you think it's ok to spy on your users on a school network?
  - ChoHag 10y ago
deleted 10y ago
[deleted]
thedonkeycometh 10y ago
lolz
- sctb 10y ago
  We asked you to please not comment like this, so we've banned this account. We're happy to unban accounts if you email us at hn@ycombinator.com and we believe you'll comment only civilly and substantively in the future.
amluto 10y ago
I don't get it. This can't be about decrypting traffic between internal clients and external servers, because the bank doesn't have the RSA key in the first place. It also seems unlikely that it's about decrypting traffic between external clients and internal servers, because (a) that's not what the bank rep said and (b) the server would just log the traffic. That leaves two cases: internal client <-> internal server and internal client <-> internal MITM. For both of these cases, I see two easy solutions: 1. Log the session key. 2. Define a custom TLS extension that contains the session key encrypted with against a known bank-controlled public key and have the server/MITM send this extension after the handshake. Problem solved. In any event, the internal client <-> external server case is highly problematic. What's to stop, say, Snapchat from running an extra unauthenticated DH exchange in JavaScript and encrypting all the application layer traffic against the resulting session key? The MITM proxy won't notice unless it's very clever indeed and then all those nice MITM proxy logs are useless.
shthed 10y ago
Late to the party.. heh, they agreed to remove RSA Key Transport back in April 2014, implemented in draft 02 https://www.ietf.org/mail-archive/web/tls/current/msg12266.html https://www.ietf.org/mail-archive/web/tls/current/msg12266.h... > The consensus in the room at IETF-89 was to remove RSA key transport from TLS 1.3. If you have concerns about this decision please respond on the TLS list by April 11, 2014. https://threatpost.com/tls-1-3-working-group-has-consensus-to-deprectate-rsa-key-transport/105916/ https://threatpost.com/tls-1-3-working-group-has-consensus-t... https://github.com/tlswg/tls13-spec/commit/5d861d58b8a5ef2e8628f39063ebf580fafe04e7 https://github.com/tlswg/tls13-spec/commit/5d861d58b8a5ef2e8...
winteriscoming 10y ago
I never knew that it was an accepted practice to have MITM techniques for monitoring activities in cases like the author notes in that thread. I'm not an expert but is this common? I haven't heard something like this before.

313 points by Kliment 10y ago

"...almost all of whom are running TLS internally and have significant, security-critical investments in out-of-band TLS decryption. Like many enterprises, financial institutions depend upon the ability to decrypt TLS traffic to implement data loss protection, intrusion detection and prevention, malware detection, packet capture and analysis, and DDoS mitigation. Unlike some other businesses, financial institutions also rely upon TLS traffic decryption to implement fraud monitoring and surveillance of supervised employees." And thus essentially defeating the entire purpose of TLS. Can you please help us continue doing this with the new version of TLS too. Thanks. Love. Big Banks.

rincebrain 10y ago
Only sometimes. The argument here could be whether you, as an individual working for an employer on employer-controlled hardware, have the right to communications that cannot be viewed by the employer at their discretion on those systems. Having that capability (undecryptable communication) on an exceptional basis (e.g. only a few sites or methods do it) might be grounds for blocking any instances of the protocol that negotiate that level at the border. Having every secure site do it would result in not being able to passively store and only decode the communications that, say, you have occasion to go inspect later for discovery reasons, and instead would require MITMing and downgrading all connections (and storing the traffic, at best, re-encrypted with a different key). (Note that I'm not voicing an opinion on the topic, just observing that there are legitimate reasons to desire this functionality from several perspectives, which do not necessarily imply wanting a backdoor in the protocol in the general case.)
- PeterisP 10y ago
  From a technical standpoint, the desire of <bank> to monitor all communications of a stockbroker in an easy and effective manner and being able to decrypt historical captured is identical to the desire of <evil government> to do the same for their civil rights activists. From a protocol perspective, you can't distinguish it - any new protocol either makes monitoring harder for everyone or easier for everyone, without checking if your reason is good or bad. If we choose to make communications more private, then yes, the ability to monitor stuff will suffer even if someone has a legitimate and reasonable reason to need this ability. Too bad, we've made a choice that the security of the masses is more important than this. I acknowledge that this change will hurt the banks for the reasons given above, but in this case hurting them is an unavoidable cost of helping most everyone else.
  - rincebrain 10y ago
    Sure, from a protocol perspective, arranging it so nobody, even the original owner, can decrypt the communication after the fact is beneficial, except that now, you end up with people downgrading such communications or storing the session secret keys, the latter probably by patching software crypto implementations where possible (since I doubt any of the major crypto implementations would agree to storing those keys even with an --i-am-a-developer-really-stop-bothering-me flag). I hope I'm wrong. I don't want to end up in a world where all enterprises actively MITM and negotiate down to non-PFS protocols to avoid this, or hack up the software stacks on their machines to circumvent this (with all the overhead that implies - echoes of "requires Internet Explorer 5" for how old some of this will probably get between updates). I just don't think that the people who make use of this functionality are going to let it go, no matter what it takes. (That's not to say it's not worth trying, to be clear - I just foresee it ending poorly for everyone except for private individuals, and possibly even them if ISPs start requiring you accept their MITM CA.)

madmax108 10y ago

>>> My view concerning your request: no. is probably the best response for the request. On a related note though, it's always amazing how on one hand Big Banking tries to show that it's in touch with the latest tech developments (Bitcoin Consortiums, RFID/NFC payments) etc. but on the other hand display a very shallow understanding of how secure systems should work.

viraptor 10y ago
I think that's a very biased way of looking at this request. They don't necessarily have a shallow understanding. They have a set of very strict rules they have to obey. If that means no privacy for the employees, then they have to implement no privacy for the employees. The reasoning of the author has been explained pretty well in my opinion. But that's completely orthogonal to the understanding how the secure systems work.
- usgroup 10y ago
  Indeed, orthogonal. I think it's a denied attempt to connect cross-purposes. I.e. design for security with practicalities of implementation in a broader context. I notice some posts argue that we should aim for a pareto-optimum and accommodate the banks, but really this should require a broad representation for the rest of the subjects of TLS 1.3 to work out exactly what the pareto would look like. Given that they are 15 drafts in, it seems to me that there has been ample opportunity.
rdtsc 10y ago
I call it paper security or checklist security. Usually it is about implementing enough to check off a list of requirements from some document. Antivirus installed? Check (Nevermind it is a Linux box and AV loads a dubious proprietary driver in the kernel with a huge attack surface and remote exploit posibility because of how it does updates), such and such EAL-4 operating system intalled? Check, and so on ... So they tick all the boxes and in the end up with a worse off posture than if they just stayed with defaults for example.
- 10y ago

pmarreck 10y ago

Well, that was kind of a burn. Was the argument by the bankers basically a complaint that retooling would be very expensive? and/or that employee surveillance would be more difficult? (yeah, I'm sure everyone is a fan of that!)

brazzledazzle 10y ago
mitm surveillance of employee traffic is basically a cornerstone of enterprise security since those networks are designed to be very squishy on the inside. Thankfully Google is turning the assumption that the perimeter needs to extend to your rather vulnerable clients on its head but that will be several years before it's productized enough that middle managers will be convinced to buy it by a VAR over a game of golf.
- fulafel 10y ago
  Highly culture and jurisdiction dependent. Many places ban this with some narrow exceptions (defense sector etc) in law and/or binding labour org agreements.
- ChoHag 10y ago
  That's basically putting the cart before the horse. Security is hard. Hard problems are easier when there are fewer of them. It's easier to build one big wall than lots of little ones. Surveillance of employees is a cornerstone of enterprise security because humans are inherently untrustworthy. One part of the solution to this problem is to define a distinction (using golf[+] of all things as an analogy) between the rough, the fairway and the green. Because defining a border between the rough and the course is easy, and untrustworthy humans aren't all that bad most of the time, the distinction between the fairway and the green easily becomes blurred. While employers may polish up the distinction between their workaday desktops and their locked-down servers they will never abandon the difference, and nor should they, between their systems and everyone else's systems. [+] You have my permission to use this analogy with your manglers.
  - brazzledazzle 10y ago

jrockway 10y ago

I don't understand why the banks need to change TLS 1.3 to spy on their employees. When I was working at a bank, there were literally no routes from the Intranet to the Internet. Everything went through a proxy that blocked 95% of the Internet. Had to run a proxy server on jrock.us in order to get anything done. (They just bought the list of sites to block, and jrock.us never ended up on it. Blacklisting, very good security technique...)

notyourwork 10y ago
Who doesn't love a game of wack-a-mole?
- ChoHag 10y ago
  Why else is OP still employed?
zigzigzag 10y ago
The guy's rationale may be kind of dubious but it's clearly stated: there aren't any tools that do DPI on TLS 1.3 sessions right now.
- jrockway 10y ago
  You don't need to do deep packet inspection when you just MITM all the traffic.
  - blazespin 10y ago
    Infrastructure upgrades are required. tls1.3 will be expensive
    - vacri 10y ago
      So let the CEOs have a year of $40M bonuses instead of $50M bonuses. A small price to pay for better security for the rest of us.

kbart 10y ago

"Like many enterprises, financial institutions depend upon the ability to decrypt TLS traffic to implement data loss protection, intrusion detection and prevention, malware detection, packet capture and analysis, and DDoS mitigation. Unlike some other businesses, financial institutions also rely upon TLS traffic decryption to implement fraud monitoring and surveillance of supervised employees." I'm at lost here. What's the point of having TLS if it can be easily decrypted? Why not to ditch it altogether then? All this argument sounds somewhat fishy, just because your practices rely on insecure behavior, it doesn't mean it shouldn't be fixed for the rest of us.

viraptor 10y ago
You still get the verification of the other side and still get the encryption on the wire, preventing external MitM. It's just TLS benefiting the company in general, not users separately. You do not want your outgoing traffic to partners and APIs to go out in plaintext. Basically the model changes from Alice <internet> Bob to Alice, Alice's employer <internet> Bob.
xorgar831 10y ago
They key phrase is "rely upon", meaning they went down a route of using a clever hack rather than formally designing a system to meet their goals. I wonder why SOCKs proxies, which every browser supports, wouldn't work for them.
- viraptor 10y ago
  When you use a SOCKS proxy, your traffic is still encrypted from user to server. It wouldn't help them decrypt historic TLS sessions on request.
  - xorgar831 10y ago
    rather a regular http proxy that every browser supports And exactly as expected, they have a MSFT stack so they're wedged and think changing the spec is the right way to solve it. Sigh. > With TLS 1.2 we can ask the end user to take a Wireshark trace and then decrypt it with the RSA private key. With TLS 1.3 we will have to rely on the SSLKEYLOGFILE feature in Firefox and Chrome, so we want it to be available. Unfortunately, Microsoft does not allow this functionality, which is a problem in a TLS 1.3 only environment.

CDokolas 10y ago

Well, North Korea is not complaining about TLS 1.3, why would banks have to? Their proxy servers are already MITM platforms that meet their needs for security.

askmike 10y ago
Probably because Bank employees/customers use modern browsers/devices which will at some point drop support for anything but TLS 1.3. I don't think this will happen in North Korea.

deleted 10y ago

[deleted]

lexman0 10y ago

There are a lot of keyboard warriors in this thread. This guy puts forward a rational argument for big business. Unless you have extensive experience in this area, perhaps you shouldn't be so quick to judge "oh they are just spying on their users". The simple answer to this question is that if a way is not given for businesses to decrypt their own traffic that they generated and encrypted, they simply won't encrypt it. Take this example: A regulation says that all incoming traffic into a banking sector company must be scanned for potential vulnerabilities and exploits, and allows for "compensating controls". If the incoming traffic is unable to be decrypted at TLS1.3, it will simply be decrypted at the boarder of the business and routed internally unencrypted. This would be worse than copying the TLS1.2 traffic for out-of-band scanning. I'm not saying that this guy wasn't a little late by the party, but failing to recognise that big businesses have regulations you don't understand or even care about is a huge mistake that will make us all more insecure. After all, who doesn't have a bank account?

4ad 10y ago
> After all, who doesn't have a bank account? But rules and regulations shield me and give me legal and financial aid for the stupid thing my bank might do.
- lexman0 10y ago
  True enough. But those who steal your account information and use it to pose as you don't follow the rules and regulations.
  - 4ad 10y ago
    But the bank follows the regulations that tell it to give me all my money back, if there's some fraud. I don't have any money to lose if the bank does not implement security properly. Only the bank has to lose.
    - pdpi 10y ago
      They'll refund you after you've already lost the money, or the attacker might use the bank details as part of larger-scale identity theft that might come to leave you in hot water with law enforcement if he uses your identity to commit a crime. All that inconvenience is your own loss, and the bank paying damages for that doesn't really "fix it"

anonymousDan 10y ago

I don't quite get what they are currently doing. Is it that they have some kind of Internal mitm proxy that proxies every TLS session with external hosts, recording the conversation for later offline analysis? Why wouldn't they still be able to do that? Or are they just worried about their ability to intercept internal conversations? I'd be really interested to know what a typical bank security architecture looks like, does anyone have a reference for further reading perhaps?

4ad 10y ago
They don't MITM, they record sessions and later decrypt out-of-band as needed. With TLS 1.3, they would need to MITM, which require infrastructure changes and potentially affects the performance. They are complaining TLS 1.3 forces them to do work they otherwise wouldn't have to do.
- anonymousDan 10y ago
  But how doe they get access to the keys for the session without modifying the end hosts or MITM'ing the traffic?
  - 4ad 10y ago
    > without modifying the end hosts They have full control of the end hosts. That's why the group policy forces you to use Internet Explorer instead of letting you use Firefox.
    - anonymousDan 10y ago
      Hmm, but why can't they just then record the session keys as before even for forward secure TLS (presuming we are talking about clients inside the bank initiating TLS sessions to external parties)?
      - ChoHag 10y ago
        Ah well they're banks you see and "doing things" requires spending money which they're rather averse to. Also never use the word just outside the context of law.

perlgeek 10y ago

Isn't it pretty much standard for such organizations to have decrypting and re-encrypting proxy, with their own CA that clients have to trust? If they do, I don't see how forward secrecy changes much, and they just have to tap the plain text from the proxy. If they don't, I'm seriously surprised.

akvadrako 10y ago
The original message does make dubious claims, but a little later in the thread, the real issue becomes clear. from https://mailarchive.ietf.org/arch/msg/tls/1n1tQSGKMBJKsmuCe-j-GPACvZw https://mailarchive.ietf.org/arch/msg/tls/1n1tQSGKMBJKsmuCe-... "With TLS 1.2 we can ask the end user to take a Wireshark trace and then decrypt it with the RSA private key. With TLS 1.3 we will have to rely on the SSLKEYLOGFILE feature in Firefox and Chrome, so we want it to be available. Unfortunately, Microsoft does not allow this functionality, which is a problem in a TLS 1.3 only environment." As I understand their argument, if you control the server (and hence private key and cipher suite) you can store the traffic without MITM and later decrypt it if needed. With forward secrecy, that isn't possible.
- ghshephard 10y ago
  If you control the server, you can decrypt any time you want, because obviously if you were able to decrypt at one time, you can do so later.
  - akvadrako 10y ago
    That's the whole point of forward secrecy. For the one session you use a temporary key which can't be recovered later. You can only decrypt the stream if you store that key.
    - deleted 10y ago
      [deleted]
    - merb 10y ago
      well your proxy can just store everything in Plain Text? I mean if you really need to decrypt it later you already saved it somewhere, however you can just store the plain text since your proxy already has that?

heisenbit 10y ago

It may well be that from a business perspective a greater threat to banking is coming from insiders, failing systems and incompetence than from outsiders exploiting TLS weaknesses. To those wondering why banks are worried about their employees communication even internally keep in mind that there have been very expensive judgements related to banking employees conspiring to break legal or other regulatory rules. The alternative namely monitoring on the end points is hard to implement comprehensively and a lot more expensive. If (and that is a big iff) the banking use case really justifies a special and weaker transport protocol then maybe it should be upon the banks bear the whole cost of doing that. It would also clearly assign the responsibility when things may fail from a security perspective. Maybe the end point alternative looks then more attractive.

akvadrako 10y ago

A more readable link: https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr6P9SCQBqA https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr...

avar 10y ago

Here's the exchange, I found this hard to read without word-wrapping: > On 22 Sep 2016, at 20:27, BITS Security <BITSSecurity at fsroundtable.org> wrote: > > To: IETF TLS 1.3 Working Group Members > > My name is Andrew Kennedy and I work at BITS, the technology policy > division of the Financial Services Roundtable > (http://www.fsroundtable.org/bits). My organization represents > approximately 100 of the top 150 US-based financial services > companies including banks, insurance, consumer finance, and asset > management firms. > > I manage the Technology Cybersecurity Program, a CISO-driven forum > to investigate emerging technologies; integrate capabilities into > member operations; and advocate member, sector, cross-sector, and > private-public collaboration. > > While I am aware and on the whole supportive of the significant > contributions to internet security this important working group has > made in the last few years I recently learned of a proposed change > that would affect many of my organization's member institutions: the > deprecation of RSA key exchange. > > Deprecation of the RSA key exchange in TLS 1.3 will cause > significant problems for financial institutions, almost all of whom > are running TLS internally and have significant, security-critical > investments in out-of-band TLS decryption. > > Like many enterprises, financial institutions depend upon the > ability to decrypt TLS traffic to implement data loss protection, > intrusion detection and prevention, malware detection, packet > capture and analysis, and DDoS mitigation. Unlike some other > businesses, financial institutions also rely upon TLS traffic > decryption to implement fraud monitoring and surveillance of > supervised employees. The products which support these capabilities > will need to be replaced or substantially redesigned at significant > cost and loss of scalability to continue to support the > functionality financial institutions and their regulators require. > > The impact on supervision will be particularly severe. Financial > institutions are required by law to store communications of certain > employees (including broker/dealers) in a form that ensures that > they can be retrieved and read in case an investigation into > improper behavior is initiated. The regulations which require > retention of supervised employee communications initially focused on > physical and electronic mail, but now extend to many other forms of > communication including instant message, social media, and > collaboration applications. All of these communications channels > are protected using TLS. > > The impact on network diagnostics and troubleshooting will also be > serious. TLS decryption of network packet traces is required when > troubleshooting difficult problems in order to follow a transaction > through multiple layers of infrastructure and isolate the fault > domain. The pervasive visibility offered by out-of-band TLS > decryption can't be replaced by MITM infrastructure or by endpoint > diagnostics. The result of losing this TLS visibility will be > unacceptable outage times as support groups resort to guesswork on > difficult problems. > > Although TLS 1.3 has been designed to meet the evolving security > needs of the Internet, it is vital to recognize that TLS is also > being run extensively inside the firewall by private enterprises, > particularly those that are heavily regulated. Furthermore, as more > applications move off of the desktop and into web browsers and > mobile applications, dependence on TLS is increasing. > > Eventually, either security vulnerabilities in TLS 1.2, deprecation > of TLS 1.2 by major browser vendors, or changes to regulatory > standards will force these enterprises - including financial > institutions - to upgrade to TLS 1.3. It is vital to financial > institutions and to their customers and regulators that these > institutions be able to maintain both security and regulatory > compliance during and after the transition from TLS 1.2 to TLS 1.3. > > At the current time viable TLS 1.3-compliant solutions to problems > like DLP, NIDS/NIPS, PCAP, DDoS mitigation, malware detection, and > monitoring of regulated employee communications appear to be > immature or nonexistent. There are serious cost, scalability, and > security concerns with all of the currently proposed alternatives to > the existing out-of-band TLS decryption architecture: > > - End point monitoring: This technique does not replace the > pervasive network visibility that private enterprises will lose > without the RSA key exchange. Ensuring that every endpoint has a > monitoring agent installed and functioning at all times is vastly > more complex than ensuring that a network traffic inspection > appliance is present and functioning. In the case of monitoring > of supervised employee communications, moving the monitoring > function to the endpoint raises new security concerns focusing on > deliberate circumvention - because in the supervision use case > the threat vector is the possessor of the endpoint. > > - Exporting of ephemeral keys: This solution has scalability and > security problems on large, busy servers where it is not possible > to know ahead of time which session is going to be the important > one. > > - Man-in-the-middle: This solution adds significant latency, key > management complexity, and production risk at each of the needed > monitoring layers. > > Until the critical concerns surrounding enterprise security, > employee supervision, and network troubleshooting are addressed as > effectively as internet MITM and surveillance threats have been, we, > on behalf of our members, are asking the TLS 1.3 Working Group to > delay Last Call until a workable and scalable solution is identified > and vetted, and ultimately adopted into the standard by the TLS 1.3 > Working Group. > > Sincerely, > > Andrew Kennedy > Senior Program Manager, BITS The reply: To: BITS Security <BITSSecurity at fsroundtable.org> Subject: Re: [TLS] Industry Concerns about TLS 1.3 From: "Paterson, Kenny" <Kenny.Paterson at rhul.ac.uk> Date: Thu, 22 Sep 2016 19:14:25 +0000 [...] Hi Andrew, My view concerning your request: no. Rationale: We're trying to build a more secure internet. Meta-level comment: You're a bit late to the party. We're metaphorically speaking at the stage of emptying the ash trays and hunting for the not quite empty beer cans. More exactly, we are at draft 15 and RSA key transport disappeared from the spec about a dozen drafts ago. I know the banking industry is usually a bit slow off the mark, but this takes the biscuit. Cheers, Kenny

Nursie 10y ago

While they were very late to the party, this is important for some sectors. Not the reliance on specific tech (RSA) but being able to go back and decrypt their own traffic later, with appropriate keys. They need to routinely spy on some of their people,amd trace what happens to their money. Not sure why this is a problem. Their use-cases are different to (say) a user of Signal.

askmike 10y ago
> They need to routinely spy on some [..] people Unfortunately this is very far removed from the goals of the IETF, who is striving for a more secure internet.

knorker 10y ago

> Exporting of ephemeral keys: This solution has scalability and security problems on large, busy servers where it is not possible to know ahead of time which session is going to be the important one. I don't buy it. You can store entire sessions worth of data, but can't also optionally save metadata? Yes, I realise you may not want to store it for all connections, but if you don't want to have a "should I store" oracle inline with the connections, then do it async and skip writing it do disk/storage service once the answer comes back.

saurik 10y ago

Welcome to almost two weeks ago? Given how many people seem to be upvoting and commenting on this link, was everyone else on vacation for some holiday I don't celebrate when this came up multiple times before? https://news.ycombinator.com/item?id=12560284 https://news.ycombinator.com/item?id=12560284 https://news.ycombinator.com/item?id=12561004 https://news.ycombinator.com/item?id=12561004 https://news.ycombinator.com/item?id=12563481 https://news.ycombinator.com/item?id=12563481

veeti 10y ago
This had a much catchier, editorialized title earlier.

FuckOffNeemo 10y ago

Wouldn't this be solved by having multiple SSL offload reverse proxies at the points you want to decrypt traffic?

phkamp 10y ago

This is exactly the clash between governments (here financial regulation) and cyberlibertarians I wrote about earlier this year: http://queue.acm.org/detail.cfm?id=2904894 http://queue.acm.org/detail.cfm?id=2904894 What have we gained in security, if TLS1.3 is basically illegal to use for banks ? Who wins if browsers refuses to connect to web-banking which operates inside the boundaries of the law ?

aseipp 10y ago
But they're claiming it will require overhauling their infrastructure and cost money to do -- not that it's impossible to support, or that TLS 1.3 will "be illegal" if their demands are not met (this is just nonsense and 100% FUD on part of your comment, honestly -- and I say that as someone who thinks highly of your work). Furthermore there's no clear evidence TLS 1.2 will be deprecated anytime soon, so these people have years to sort out the details with their vendors to have replacements in-flight. Banks have money and connections. They'll survive this and evolve. In any case, they could have made their concerns available earlier to the standards body. Like, over two and a half years ago (RSA key exchange was removed in early 2014). This is hardly the fault of "cyberlibertarians" or whatever, this is just these people being out of touch. The alternative here would be that these guys get to butt into the standardization process and demand changes at the very last moment, after years of work, with no negative impacts or consequences for them -- for what is ultimately a small portion of the overall internet. Why would we want that? It completely undermines the authority of the IETF and the entire point of a standards process if "really important" people can just completely railroad it and demand changes on a whim with no consequences to themselves. Frankly, completely ignoring the actual content of the request, this alone is pretty bad behavior on their part. Why we should worsen the security of billions of people, and introduce complexity into a vital internet protocol, so that those dorks can have slightly higher profit margins -- I dunno. Designing a security protocol is hard enough. If they didn't want to pay attention to the conversation, and now want to cry their pockets will take a hit -- well, maybe they'll learn and be more proactive next time and save themselves some cash. > Who wins if browsers refuses to connect to web-banking which operates inside the boundaries of the law ? Nobody ever said TLS 1.3 would be illegal for banks, that browsers are going to immediately drop TLS 1.2 after this (both of these two being a requirement for your prediction to be true -- lol, and also completely asinine) making it refuse to connect to a "law abiding bank", or that moving to TLS 1.3 would be literally impossible for them forever and can't be solved. This is just complete FUD dude, c'mon. Unless you're actually interested in the answers to completely nonsense hypotheticals made up out of thin air, I guess...

stephen_g 10y ago

I think this request is pretty unreasonable, and anything that stops the ability to passively snooping on TLS is a great thing. I think there could be a security gain though in adding support for a better way to actively MITM TLS traffic though - in having a proper mechanism for filtering proxy firewalls. For some applications (say, school networks) it is OK to monitor and filter traffic, but the way it is done now is terrible for security. Usually this is by terminating the TLS at the proxy, scanning it, and then re-encrypting it with an certificate automatically generated and trusted by an internal CA (whose root certificate is installed on the machines). The huge problem is that now everyone has to trust all the root CAs installed on the firewall, instead of being able to decide which ones to trust themselves. The firewall has to also decide whether or not to trust self-signed certificates. Much better would be to be able to decrypt, re-encrypt with a certificate issued by a real CA, and then also send the original certificate along with the handshake. Then, the first time you visited a TLS site, it could pop up a big warning saying 'This traffic is intercepted by firewall.institution.edu, do you consent?' and have a little exclamation mark in the toolbar to always indicate that it's being intercepted. The browser would have to trust both the interception certificate (which encrypts between the firewall and the endpoint inside the internal network) as well as getting the original certificate and deciding whether to trust that (which you don't get now).

deleted 10y ago
[deleted]
bchociej 10y ago
I like your proposed (user-visible) solution quite a lot, this would be great. I predict certain folks would respond to this by trapping themselves in the indefensible position of "but if they know we're intercepting them, how will we catch them being bad?!?!"
Tharkun 10y ago
Why do you think it's ok to spy on your users on a school network?
- ChoHag 10y ago

deleted 10y ago

[deleted]

thedonkeycometh 10y ago

lolz

sctb 10y ago
We asked you to please not comment like this, so we've banned this account. We're happy to unban accounts if you email us at hn@ycombinator.com and we believe you'll comment only civilly and substantively in the future.

amluto 10y ago

I don't get it. This can't be about decrypting traffic between internal clients and external servers, because the bank doesn't have the RSA key in the first place. It also seems unlikely that it's about decrypting traffic between external clients and internal servers, because (a) that's not what the bank rep said and (b) the server would just log the traffic. That leaves two cases: internal client <-> internal server and internal client <-> internal MITM. For both of these cases, I see two easy solutions: 1. Log the session key. 2. Define a custom TLS extension that contains the session key encrypted with against a known bank-controlled public key and have the server/MITM send this extension after the handshake. Problem solved. In any event, the internal client <-> external server case is highly problematic. What's to stop, say, Snapchat from running an extra unauthenticated DH exchange in JavaScript and encrypting all the application layer traffic against the resulting session key? The MITM proxy won't notice unless it's very clever indeed and then all those nice MITM proxy logs are useless.

shthed 10y ago

Late to the party.. heh, they agreed to remove RSA Key Transport back in April 2014, implemented in draft 02 https://www.ietf.org/mail-archive/web/tls/current/msg12266.html https://www.ietf.org/mail-archive/web/tls/current/msg12266.h... > The consensus in the room at IETF-89 was to remove RSA key transport from TLS 1.3. If you have concerns about this decision please respond on the TLS list by April 11, 2014. https://threatpost.com/tls-1-3-working-group-has-consensus-to-deprectate-rsa-key-transport/105916/ https://threatpost.com/tls-1-3-working-group-has-consensus-t... https://github.com/tlswg/tls13-spec/commit/5d861d58b8a5ef2e8628f39063ebf580fafe04e7 https://github.com/tlswg/tls13-spec/commit/5d861d58b8a5ef2e8...

winteriscoming 10y ago

I never knew that it was an accepted practice to have MITM techniques for monitoring activities in cases like the author notes in that thread. I'm not an expert but is this common? I haven't heard something like this before.