Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Security Impact of HTTPS Interception [pdf]

jhalderm.com

Post reply on HN
Print view View original

61–67 of 67 posts

Re: The Security Impact of HTTPS Interception [pdf]

#61

Post by Spooky23 »

simias wrote: post #8

I was surprised by this note (on page 2): > Contrary to widespread belief, public key pinning [19] — an HTTPS feature that allows websites to restrict connections to a specific key — does not prevent this interception. Chrome, Firefox, and Safari only enforce pinned keys when a certificate chain terminates in an authority shipped with the browser or operating system. The extra validation is skipped when the chain ter…

Absolutely not. The owners of IT systems need to be able to assert control over what enters and leaves the system.

Allowing uninspected outbound traffic makes it trivial for an attacker to exfiltrate data, an employee to accidentally or purposely release data, etc.

Re: The Security Impact of HTTPS Interception [pdf]

#62

Post by ploxiln »

the8472 wrote: post #33
pfg wrote: post #10

Earlier quoted context omitted.

Trying to fight a local attacker with root (which is necessary to add a certificate to the trust stores on most platforms) isn't worth the effort. It's easy for the admin to bypass and would cause even more warning fatigue. That's not to say I disagree with the sentiment that this is something employers (and other organizations providing access to devices) should be obliged to disclose, but that is perhaps more of a…

> Trying to fight a local attacker with root (which is necessary to add a certificate to the trust stores on most platforms) isn't worth the effort. Hah. That's precisely the argument I have made when arguing that there should be an opt-out for addon signature verification (needing admin permissions to toggle it if they insist) because you already utterly lost the security game if someone had admin on the machine. Bu…

I agree. But the reason they felt forced to do this is because even "reputable" software companies were auto-injecting unnecessary extensions as a side-effect of installing their popular software. Companies like Adobe and Microsoft, and "industry leading" "computer security" companies.

My first instinct is to say "it's important to not install crap software, you need to reasonably trust the software you install". But I immediately recognize that it's un-intuitive that Adobe and Microsoft and Symantec and McAfee are not on the "trusted" list. (Office and .Net have silently installed problematic Firefox extensions in the past.)

I don't really have a conclusion here, just, it sucks.

Re: The Security Impact of HTTPS Interception [pdf]

#63

Post by LogicX »

Artemis2 wrote: post #50
LogicX wrote: post #31

I'll jump on my current soap box, which is that we need a standard to allow MITM blocking, without interception, and a nicer user experience. This won't solve all use-cases, but selfishly, It will solve mine at DNSFilter: If a browser could recognize our SSL cert, or a special field in our cert, and present the user with a block message, and a static link to learn more, it would eliminate the need for us to have our…

I've written a proxy that uses SNI to filter outgoing connections based on the domain name, without decrypting the traffic. It's not exactly user-friendly as you'd like, but it's a good solution to our use-case. I might open-source it if there's interest but it's relatively basic.

I'd be interested in seeing what you've got -- I have on my list to look into doing so with HAProxy per the link here: http://serverfault.com/questions/628147/nginx-proxy-based-on...

Re: The Security Impact of HTTPS Interception [pdf]

#64

Post by cesarb »

closeparen wrote: post #57
cesarb wrote: post #30

Earlier quoted context omitted.

There's another way to do that: require client certificates. The MITM proxy cannot present the client certificate to the server, since it doesn't have the corresponding private key. Unfortunately, the user interface for client certificates is a complete pain, so they are rarely used. But they're the only true way for a server to make sure it's talking directly to a client, in the same way server certificates can allo…

>The MITM proxy cannot present the client certificate to the server, since it doesn't have the corresponding private key. The MITM proxy is operated by the same department that has root on all the endpoints it's intercepting. If necessary, the "endpoint protection" product will grab the private key, or just scrape the details of the browser session from the browser's memory rather than at network level.

Grabbing the client certificate private key is not always possible; it can be on a smart card (and even when on a file, it could be password-protected). Also, the operators of the MITM proxy do not necessarily have root on the endpoints (they can require the users to add the CA certificate themselves), and even if they have, scraping the session keys from the often-updated browser is not trivial.

Re: The Security Impact of HTTPS Interception [pdf]

#65

Post by eeZah7Ux »

loup-vaillant wrote: post #52
riffic wrote: post #44

Earlier quoted context omitted.

Don't use your work computer for things you don't want your work to be able to detect, intercept & modify. with that logic, don't get mail sent to the office because your employer has every right to open and reseal the envelope. You know who also has that right? Prisons.

That's employment for you. Employees are not treated as autonomous agents. More like untrustworthy children. For my last gig, I worked at some company on behalf of another. This workplace was quite explicit about intercepting and monitoring everything. I pondered for a second whether I should use this place's computers to log to my employer's webmail. I gave up and did it, because I wasn't going to read or write work…

> That's employment for you.

This might be true in the US but illegal in various other countries!

Re: The Security Impact of HTTPS Interception [pdf]

#66

Post by loup-vaillant »

eeZah7Ux wrote: post #65
loup-vaillant wrote: post #52

Earlier quoted context omitted.

That's employment for you. Employees are not treated as autonomous agents. More like untrustworthy children. For my last gig, I worked at some company on behalf of another. This workplace was quite explicit about intercepting and monitoring everything. I pondered for a second whether I should use this place's computers to log to my employer's webmail. I gave up and did it, because I wasn't going to read or write work…

> That's employment for you. This might be true in the US but illegal in various other countries!

That's… murky. I live in France, where your correspondence is supposed to stay secret. It obviously applies to personal snail mail, and arguably personal e-mail. It should apply to every personal IP packet (they're structurally closer to snail mail than an e-mail is), but I don't know if it does.

Work stuff… When you use the work computer to do stuff on behalf of your employer, it's not really private, and could arguably be monitored. (There are work regulations that limit how you can use that data however. Benchmarking for instance is forbidden in France.)

The problem is, since proxy servers cannot automatically distinguish work related activities from personal errands, they tend to cast a wide net. The implied distrust kinda disgusts me, but I reckon this puts big companies in a delicate situation: one does not simply trust thousands of people —too many single points of failure.

Re: The Security Impact of HTTPS Interception [pdf]

#67

Post by znewman »

riffic wrote: post #44
zeveb wrote: post #36

Earlier quoted context omitted.

> Employees are often required to install local certs (or applications/scripts that do that) - that doesn't mean the host is entirely compromised. If they are forced to install those certs, then the computers they use belong to their employers, and those computers are obeying their proper owners. I fail to see the problem. Don't use your work computer for things you don't want your work to be able to detect, intercep…

Don't use your work computer for things you don't want your work to be able to detect, intercept & modify. with that logic, don't get mail sent to the office because your employer has every right to open and reseal the envelope. You know who also has that right? Prisons.

Yes and that's well within their right and within most companys' policies.. Why would you send personal mail to your workplace?
Post reply on HN