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

121–130 of 138 posts

Re: Internet protocols are changing

#121

Post by jacksmith21006 »

zb3 wrote: post #39
topspin wrote: post #12

Earlier quoted context omitted.

It seems to me that all of the changes described in this story will contribute to thwarting intermediaries and their agendas. HTTP/2 and its "effective" encryption requirement are proof against things like Comcast's nasty JavaScript injection[1]. QUIC has mandatory encryption all the way down; even ACKs are encrypted, obviating some of the traditional throttling techniques. And as you say TLS 1.3 and DOH further prot…

But I, as an user, want to be able to block domains, inject scripts and see what Chrome is sending to Google on my own devices (which is what Google doesn't want me to do). That's why I can't support these protocols...

Incorrect. You can on your end but Google stops the people in the middle which is what we want.

Re: Internet protocols are changing

#122

Post by Shoothe »

dylz wrote: post #116
Shoothe wrote: post #114

Earlier quoted context omitted.

Do you mean accessing Office 365 via browser uses SRV records or something different?

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.

Re: Internet protocols are changing

#123

Post by catern »

tptacek wrote: post #119
JoshTriplett wrote: post #118

Earlier quoted context omitted.

I'm wondering the reverse: what's the advantage to building on UDP, other than passing routers that for some reason are inclined to pass UDP but reject IP protocols they don't know? You said that this was "what UDP was for", and I was hoping for some more detail there on why UDP helps. As you said, it's just 8 bytes and a trivial checksum.

The advantage to building on UDP is that it gets through (some) middleboxes; that's what the 4 bytes of port numbers buys you. That, and the fact that UDP is designed to be the TCP/IP escape hatch for things like SCTP that don't want TCP's stream and congestion control semantics.

So there's no advantage other than getting through broken middleboxes?

Re: Internet protocols are changing

#124

Post by zb3 »

jacksmith21006 wrote: post #121
zb3 wrote: post #39

Earlier quoted context omitted.

But I, as an user, want to be able to block domains, inject scripts and see what Chrome is sending to Google on my own devices (which is what Google doesn't want me to do). That's why I can't support these protocols...

Incorrect. You can on your end but Google stops the people in the middle which is what we want.

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

Re: Internet protocols are changing

#125

Post by tptacek »

catern wrote: post #123
tptacek wrote: post #119

Earlier quoted context omitted.

The advantage to building on UDP is that it gets through (some) middleboxes; that's what the 4 bytes of port numbers buys you. That, and the fact that UDP is designed to be the TCP/IP escape hatch for things like SCTP that don't want TCP's stream and congestion control semantics.

So there's no advantage other than getting through broken middleboxes?

No, another advantage is that you can do UDP entirely in userland without privilege.

What allocating a new IP protocol says is pretty close to "all bets are off, and we're carefully taking responsibility for how every system that interacts with TCP/IP headers will handle these packets". Since SCTP doesn't need that, there's no upside. It's vanity and bloody-mindedness.

Re: Internet protocols are changing

#126

Post by slrz »

vbezhenar wrote: post #92
tptacek wrote: post #61

Earlier quoted context omitted.

Corporate ones sure don't. Even outgoing HTTP is passed through proxies on most bigco networks I've worked at.

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 can do.

Re: Internet protocols are changing

#127

Post by slrz »

fiddlerwoaroof wrote: post #47
JoshTriplett wrote: post #41

Earlier quoted context omitted.

You, as a user, absolutely can. An ISP or network administrator who does not control the endpoints, on the other hand, cannot, by design. That's a feature.

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.

Re: Internet protocols are changing

#128

Post by slrz »

zb3 wrote: post #124
jacksmith21006 wrote: post #121

Earlier quoted context omitted.

Incorrect. You can on your end but Google stops the people in the middle which is what we want.

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?

Re: Internet protocols are changing

#130

Post by slrz »

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.

Post reply on HN