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

Internet protocols are changing

blog.apnic.net

Post reply on HN
Print view View original

131–138 of 138 posts

Re: Internet protocols are changing

#131

Post by zb3 »

slrz wrote: post #128
zb3 wrote: post #124

Earlier quoted context omitted.

How can I decrypt QUIC traffic then? Do Wireshark and mitmproxy support QUIC? Will DOH respect /etc/hosts files?

Patch your program to dump the keys or traffic?

I know that I could edit the source code and recompile the program. I know I could disassemble the binary, find out addresses of functions and then use things like uprobes to dump/modify registers/memory. I know that in theory I could write my own version of mitmproxy that supports QUIC. But I don't have time to do all that, and that's why I speak against those protocols (which changes nothing anyway)

Re: Internet protocols are changing

#132

Post by gsich »

slrz wrote: post #126
vbezhenar wrote: post #92

Earlier quoted context omitted.

If they want to only allow proxied HTTP, that's their decision and developers should respect that, and not mask everything under HTTP. Their administrators made a substantial effort to forbid everything, why would honest person try to overcome their effort? Home routers is another matter, home users don't make conscious decision about it, but in my experience UDP works just fine (because a lot of games use it) and it…

Because in many cases, those administrators don't even realize they're breaking the network. They just run a botched config that they inherited from their predecessors or something like that. You might say that they're clueless and shouldn't be allowed near networking equipment (and you might even be right) but it's not going to change a thing. For the foreseeable future, working around broken environments is all we…

It's not. Talk to them. If you really need port XYZ open because your task requires that, you'll get the port open.

Re: Internet protocols are changing

#133

Post by Shoothe »

slrz wrote: post #129
Shoothe wrote: post #96

Earlier quoted context omitted.

Support for Client Certificates.

Heh? People use client certificates with HTTP2 all the time. Is that nonstandard?

Are you sure it's HTTP2 or just HTTP2 that was downgraded to HTTP1.1 over TLS? Last time I checked client certs did not work on HTTP2 due to multiplexing see e.g. https://www.ietf.org/mail-archive/web/httpbisa/current/msg25...

Re: Internet protocols are changing

#134

Post by fiddlerwoaroof »

slrz wrote: post #127
fiddlerwoaroof wrote: post #47

Earlier quoted context omitted.

What if I want to use my router to block telemetry domains? Or other malware sites? It’s looking like the only way forward is running my own CA to mitm all encrypted traffic.

What? You control the endpoint. No need to MITM when you can just make your browser do what you want.

Then I only solve the issue on my browser: what about my phone, and all the random other programs that phone home?

Re: Internet protocols are changing

#135

Post by marcosdumay »

ohazi wrote: post #64
marcosdumay wrote: post #58

Earlier quoted context omitted.

Corporations and governments are not two entities you can divide for conquering.

I agree with you, and it feels dirty, but we're going to end up with neither if we don't start with one. If you have a better idea that can even plausibly attempt to get both, I'm all ears.

I have no better idea, but it's a problematic plan. If you go with this, you will be surprised by underground deals that will stop that division, and will very likely mislead you.

The good part is that it focus on fixing the government. That's the correct entity to fix.

Re: Internet protocols are changing

#136

Post by g-clef »

slrz wrote: post #130
g-clef wrote: post #107

I'm really struck by how hostile to enterprise security these proposals are. Yes, I know that the security folks will adapt (they'll have to), but it still feels like there's a lot of baby+bathwater throwing going on. DNS over HTTP is a prime example: blocking outbound DNS for all but a few resolvers, and monitoring the hell out of the traffic on those resolvers is a big win for enterprise networks. What the RFC call…

As implemented, all these "enterprise security" things are mostly indistinguishable from malicious attacks. Of course they break when you start tightening security. Forging DNS responses is a horrible idea (and already breaks with DNSSEC). I have a hard time to comprehend how this can be considered a reasonable security measure.

> I have a hard time to comprehend how this can be considered a reasonable security measure.

OK, let's walk it through.

Task: block access to "attacker.com" and all it's subdomains. Reason: Maybe it's a malware command and control, maybe it's being used for DNS tunneling, whatever. Blocking a domain that's being used for malicious behavior is a reasonable thing for an enterprise to want to accomplish.

Option 1: Block by IP at the firewall. Problems: Attackers can simply point the domain to another IP, so you're constantly playing whack-a-mole and constantly behind the attacker. Also, if it's a DNS tunnel the DNS answer is what's interesting, not the traffic to the actual IP. Result: Fail, doesn't solve the problem.

Option 2: Block by DNS Name at the firewall. Problems: Requires the firewall to understand the protocols involved, which they have shown themselves to be inconsistent at, at the best of times. Also, doing regex on every DNS query packet(in order to find all subdomains) doesn't scale. Result: Fail, doesn't scale.

Option 3: Block with local agent. Problems: Tablets, phones, appliances, printers can't run a local agent. Result: Fail. Not complete coverage

Option 4: Block outbound DNS except for approved resolvers, give those resolvers an RPZ feed of malicious domains. Problem: Clients have to be configured to use those resolvers, but otherwise none. Result: Pass. It's standards compliant, and DNSSec isn't an issue since the resolver never asks for the attackers DNS answer, so they never get the chance to offer DNSSec.

That's why option 4 (or some variant of it) is popular in enterprises. It accomplishes the task in a standards-compliant way, and covers the entire enterprise in a way that scales well.

DOH blows this up. So, the question becomes: in a world with DOH, how is an enterprise supposed to completely and scalably block access to "attacker.com" and all its subdomains? So far, the answer has been "you don't." I think that is a really shitty answer to someone who's trying to accomplish something reasonable.

Re: Internet protocols are changing

#137

Post by teddyh »

Shoothe wrote: post #122
dylz wrote: post #116

Earlier quoted context omitted.

o365 general services (lync skype, outlook, ... / exchange autodiscover) uses SRV a fair bit. 365 is not just the browser suite

Yeah but the services that you mentioned are used mostly by enterprises. It's still possible that SRV lookups are broken for large amount of consumers that are not enterprises.

And I wonder who that could be, if that is even true.

Re: Internet protocols are changing

#138

Post by Dylan16807 »

g-clef wrote: post #136
slrz wrote: post #130

Earlier quoted context omitted.

As implemented, all these "enterprise security" things are mostly indistinguishable from malicious attacks. Of course they break when you start tightening security. Forging DNS responses is a horrible idea (and already breaks with DNSSEC). I have a hard time to comprehend how this can be considered a reasonable security measure.

> I have a hard time to comprehend how this can be considered a reasonable security measure. OK, let's walk it through. Task: block access to "attacker.com" and all it's subdomains. Reason: Maybe it's a malware command and control, maybe it's being used for DNS tunneling, whatever. Blocking a domain that's being used for malicious behavior is a reasonable thing for an enterprise to want to accomplish. Option 1: Block…

If the attacker can get new IPs, they can get new domains. Why is pure domain-blocking a goal in the first place?

The one-size-fits-all answer with DOH is the same as without it: Tell your devices to use/trust the MitM.

Post reply on HN