181–190 of 194 posts
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 s…
Who doesn't love a game of wack-a-mole?
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!)
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…
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.
Earlier quoted context omitted.
> 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.
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)?
Also never use the word just outside the context of law.
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 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 ?
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…
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 i…
If they just store traffic and can decrypt it afterwards with the private key that they likely already protect with very high security, I think that's better than having to log traffic and all the session keys which need to be protected in the same manner as the private key... I agree that his message was a rational argument. The dismissive response was disappointing, however. Ultimately, the conflict of interest her…
The point of "perfect" forward security is that it's not possible to recover session keys using only the secret key and the (logged) handshake data.
One solution would be to modify the server's stack to use kerberos or some other low-overhead encrypted channel to send the session keys to the logging server so that the session keys can be logged along with the encrypted data. Another, less scalable, solution would be to have a border proxy set up the TLS 1.3 session keys and then set up a connection from the border proxy to the internal server using TLS 1.3 PSK such that the internal and external connections use the same session key. Both of these solutions would allow a border proxy to decrypt and filter traffic without the overhead of having the border proxy decrypt and re-encrypt the traffic. The border proxy could decrypt and process traffic, and if no problems are found, forward the still-encrypted data to the internal server.
Yes, with TLS 1.3 it will be a pain to set up logs that make customer data more vulnerable to theft. It will still be possible, and multiple vendors will gladly implement it for banks and sell to banks.
Earlier quoted context omitted.
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 tha…
From a technical standpoint, the desire of 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 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…
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.)
Earlier quoted context omitted.
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.
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.
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.
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 s…
> I don't understand why the banks need to change TLS 1.3 to spy on their employees ..... run a proxy server.... You answered your own question. They need it in order to spy on YOU! Their problem isn't the "good" employees who don't do stuff like that, their problem is exactly people like you who try (and succeed) to bypass things.
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 i…
Why do you think it's ok to spy on your users on a school network?
This is talking about providing internet for educational purposes to minors. I don't really think there is any argument to say that they should not be subject to automated filtering of the content that they can use on those computers.
Even at work it's probably fair enough. An employer is well within their rights to filter the internet they provide - if you want to do private personal stuff, bring your own laptop and use an LTE dongle or tether it to your phone's internet...