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

Advice to avoid public Wi-Fi is mostly out of date

eff.org

Post reply on HN
Print view View original

101–110 of 117 posts

Re: Advice to avoid public Wi-Fi is mostly out of date

#101

Post by ozim »

PaulHoule wrote: post #24

I remember in 2005 when you could just start up Ethereal, run it for a minute, and get many people's email passwords, email, everything... I think Wi-Fi security is going to be a major FUD talking point for the telecoms as they try to justify high prices, 5G, and the rest of their trip. 5G as it exists now does little to compete with WiFi because (in the millimeter wave form) it doesn't pass through walls. The overwh…

But 5G is not meant for in house consumption. It is meant for crowded spaces like train stations, supermarkets to offload other bands. Then you get micro cells installed indoors inside of supermarkets. (what I mean by supermarket means mall and all those kind of shopping centers)

It is meant also for all kinds of smart sensors in area, but not like home sensors but utilities. We have that with LoRa, but it is really small data amounts, where 5G would be used for sensors that need more data, like smart traffic lights? Then you won't have to connect your old traffic lights to some cable network and they would get good connection capabilities.

Right now 4G is not used everywhere, in less dense areas you only get 3G. Of course providers will install base stations for 5G in places where it is economically possible. Places that have 3G now are not getting 5G anytime soon. It is also understandable that 900MHz is better for longer range than 1800MHz.

Re: Advice to avoid public Wi-Fi is mostly out of date

#102

Post by dzhiurgis »

AWildC182 wrote: post #59
iso1631 wrote: post #16

Earlier quoted context omitted.

What's the odds that the corporate network the developers are on does MITM https interception, and the only way they could get their app to work was to remove certificate validation

Been there done that. Corporate IT often doesn't want to acknowledge that devs exist in the company because it's so much easier to just lock down the admin and marketing use cases. It's fucking scary how far they're willing compromise security internally and externally to avoid extra work and maintain control.

It's amazing how well such companies can repulse developers:

- Everyone works on 8GB windows machine and sticky keyboard

- Remote desktop

- "You wanna install your IDE? Yeah contact IT, gonna take few days"

- Can't install any of cli tools

- Atlassian suite

- Spend half a day in meetings

- Scrum

Then they complain how hard it is to get a good developers...

Re: Advice to avoid public Wi-Fi is mostly out of date

#103

Post by usrusr »

ben_w wrote: post #8
mping wrote: post #5

Err, no it is not safe unless you trust the app you are running to validate the certificate chain. Not so long ago, I found out my bank's app didn't validate the cert and I could happily put a proxy and intercept all calls.

That’s an interesting point. As an app developer, I’d assumed that would be handled automatically by the OS. What’s the best way to test for certificate validity? (In my case I’m interested in iOS, but the same concern must exist on all platforms).

It's handled by your http client which may or may not be part of the OS or even something in between (speaking of Android, it's probably far more likely to be on the OS side on iOS but if the OS allows raw TCP then it can't really keep an app from running its own http(s) on top of it).

A frequent problem on android that might lead some to throw validation under the bus, is that certificate validation is much less robust than the one in browsers, particularly on old devices. A typical scenario is that the certificate of one of your backend approaches EOL, ops dutifully obtain a new one and it checks out nicely on all browsers. But a whole bunch of older Androids that might make up a quarter of your user base of you are unlucky has never heard of the root certificates involved so the app becomes unusable. A similar situation can arise if you have clients that check revocation (good) but don't check for alternative signature chains like a modern browser would do (not so good).

The correct way to solve these situations is extending the server configuration with another certificate chain that is valid on the devices in question, no doubt about that. But when the app is not a core use of the backend and there server is not run by the same organization, breaching the wall of "but it works in all browsers, clearly the error must be on your side" defense can be quite hard. Nontechnical leadership will be extremely tempted to do the writing thing.

Re: Advice to avoid public Wi-Fi is mostly out of date

#104

Post by WorldMaker »

RKearney wrote: post #58
iso1631 wrote: post #16

Earlier quoted context omitted.

What's the odds that the corporate network the developers are on does MITM https interception, and the only way they could get their app to work was to remove certificate validation

Very slim, as you can still verify the certificate chains up to a trusted root certificate and it’s trivial (and generally part of the enrollment process) to load the companies root CA on your device. We MITM and certificate validation works correctly.

Except that there should be validations at even the Root CA level and most corporate MITM CAs don't pass those verifications either:

- Is your root self-signed only? (Root CAs haven't been allowed to be self-signed only since roughly 2007 according to the principles of most browser root CA policies for public Roots. All public roots today are cross-signed among each other.)

- Does your root certificate have a valid revocation chain? Can you query up-to-date revocation information on it? (Modern Roots all have to have working revocation information, and Root CAs have been revoked in internet history, you cannot blindly trust your device's Root CA store over time without up to date revocation lists.)

Those are just two warnings I see most often from my dev tools on the MITM infrastructure I'm forced to deal with it. I know that this is compromising my security stance as a developer, and I know that turning off/ignoring those trade offs is a risk I directly pass on to users of anything I build. I've felt it a responsibility of professional ethics to pass on this concern to others in my company. I have debated many times whether if the right Root CA CVE or Self-Signed Certificate CVE comes across my dash if I will have to attempt to exercise the company's "Stop Work Authority" and refuse to continue development while being MITMed in a way that the company's security/safety infrastructure will not understand how to handle, but remains on my radar because I'm a professional and worrying about such things is my job.

Running a Root CA is a huge responsibility, and still has a ton of risks for the "real" Root CAs. (Just look at the recent battle between browser security teams and Symantec, for instance, over generating bad certificates.) Running a corporate MITM has all the same responsibility, with an even worse risk if you get it wrong (your entire company's device footprint has a single point of failure). It's such an incredible vulnerability/risk that whatever tiny gain it gives companies in surveillance over SNI sniffing and endpoint/device-deployed auditing tools is never worth the risk of subjecting so many developers to badly MITMed developer environments, especially some of the developers most at risk (bank software, health software, etc) of passing on the software equivalent of a bad MITM plague given the worst happens. I cannot imagine the blasé with which Corporate America has MITMed itself can be seen as anything but an incredible folly, if not today than certainly tomorrow (hopefully not after the worst happens).

Re: Advice to avoid public Wi-Fi is mostly out of date

#105

Post by tinus_hn »

hannob wrote: post #26
mping wrote: post #5

Err, no it is not safe unless you trust the app you are running to validate the certificate chain. Not so long ago, I found out my bank's app didn't validate the cert and I could happily put a proxy and intercept all calls.

If your app does that then it's not particularly safe over an encrypted wifi either. The solution is to fix that app, not to rely on a very weak defense that may help you in a fraction of the possible attack scenarios.

Good luck fixing your bank app. For a consumer it’s a lot easier to avoid situations where your communication is easily intercepted than it is to change the code of their banking apps.

Re: Advice to avoid public Wi-Fi is mostly out of date

#106

Post by AdamJacobMuller »

dzhiurgis wrote: post #102
AWildC182 wrote: post #59

Earlier quoted context omitted.

Been there done that. Corporate IT often doesn't want to acknowledge that devs exist in the company because it's so much easier to just lock down the admin and marketing use cases. It's fucking scary how far they're willing compromise security internally and externally to avoid extra work and maintain control.

It's amazing how well such companies can repulse developers: - Everyone works on 8GB windows machine and sticky keyboard - Remote desktop - "You wanna install your IDE? Yeah contact IT, gonna take few days" - Can't install any of cli tools - Atlassian suite - Spend half a day in meetings - Scrum Then they complain how hard it is to get a good developers...

am I the only developer(ish) who likes JIRA?

Re: Advice to avoid public Wi-Fi is mostly out of date

#107

Post by notyourday »

AdamJacobMuller wrote: post #106
dzhiurgis wrote: post #102

Earlier quoted context omitted.

It's amazing how well such companies can repulse developers: - Everyone works on 8GB windows machine and sticky keyboard - Remote desktop - "You wanna install your IDE? Yeah contact IT, gonna take few days" - Can't install any of cli tools - Atlassian suite - Spend half a day in meetings - Scrum Then they complain how hard it is to get a good developers...

am I the only developer(ish) who likes JIRA?

I think we found a yeti!

Re: Advice to avoid public Wi-Fi is mostly out of date

#108

Post by _8j50 »

What is up with these b.s posts about open or public wifi being safe this week? A few days ago there was a twitter thread by a security person at a hotel claimig their open wifi is safe.

I won't detail all the many harms you can suffer (or the threats that will readily cause you harm),but let me state just one argument related to eff's silly (and dangerously harmfull ) statement here:

1) when you type in a domain in your navigation bar, your browser attempts to connect to unencrypted http(port 80)

2) if (big if!) The site supports https it will do an http 301 redirect to the https version of the site.

3) An attacker needs to intercept just one such redirect to have an opportunity for credential theft or content injection (downloads,exploits,etc...)

3) your browser does indeed remember these redirects going forward,which is great.

4) Except if you configured your browser to forget all history. Or if you happen to remember a site you visited a while ago (perhaps on a different device) and just typed it in to navigate. Or if you typed in something to search but your browser navigates to it,or many other opportunities for pwnage!

5) you don't care about that? Well attackers are happy to setup a malicious captive portal(captive portal checks are plain http for all browsers I know of) and use that directly or to social engineer installation of an app you "need" to connect (oh,mitmproxy has a nifty captive portal like page you can customize to install a CA cert on the device for TLS interception)

I won't even begin to talk about at least half a dozen additional classes of MITM attacks that can be used, even with wpa3 and client isolation! What you have to understand is that vulns that would normally be low severity are amplified in this sort of a network, due to the sheer magnitude of threat exposure.

I can't complain about most people being ignorant to good infosec practices(we have to understand+educate) but man this stings! The eff makes one of my favorite extensions HTTPSEverywhere, how can they post this? It takes a long time to educate people about good security practices.

Re: Advice to avoid public Wi-Fi is mostly out of date

#109

Post by thwiv »

AdamJacobMuller wrote: post #106
dzhiurgis wrote: post #102

Earlier quoted context omitted.

It's amazing how well such companies can repulse developers: - Everyone works on 8GB windows machine and sticky keyboard - Remote desktop - "You wanna install your IDE? Yeah contact IT, gonna take few days" - Can't install any of cli tools - Atlassian suite - Spend half a day in meetings - Scrum Then they complain how hard it is to get a good developers...

am I the only developer(ish) who likes JIRA?

Not at all. In my opinion, it sucks, but it's the best tool available for the job.

Re: Advice to avoid public Wi-Fi is mostly out of date

#110

Post by iso1631 »

AdamJacobMuller wrote: post #106
dzhiurgis wrote: post #102

Earlier quoted context omitted.

It's amazing how well such companies can repulse developers: - Everyone works on 8GB windows machine and sticky keyboard - Remote desktop - "You wanna install your IDE? Yeah contact IT, gonna take few days" - Can't install any of cli tools - Atlassian suite - Spend half a day in meetings - Scrum Then they complain how hard it is to get a good developers...

am I the only developer(ish) who likes JIRA?

The pros and cons of jira all depends how you use it
Post reply on HN