Hacker News Reader

Comment by lkarsten | Hacker News Reader

I applaud the effort to hate on "smart" middleware proxies!

That being said, author gets no points for namedropping random distributed systems algorithms and using tcp keepalives (2 hours minimum!) as an argument against TLS terminating proxies.

Is there a reason to (as he says) "fully implement the protocol" in the proxy? I battled with websockets through Pound last week, and it simply doesn't work because the author took a non-postel stand on protocol specifics.

Having a protocol agnostic proxy like hitch (previously stud) fixed that without losing functionality, and I expect it to age better as well.

View on HN

Sadly the internet isn't as nice. I've been to various hotels where the router would silently drop keep-alive packets (but god forbid informing the packet layer you do this!) and mangled DNS packets ("looking for mail.example.com? Here is the answer for example.com" and "looking for doesnotexist.com? Here is result for internalsearchengine.com which redirects you to a sponsored search page with ads")

And this is why encrypted DNS is a must.

Even encrypted DNS will suffer because middleboxes with captive portals will attempt to tamper it.

Unless you pipe it over TLS or HTTP in which case you run into problems with not knowing why there is no connection in a captive portal (we obviously need to fix captive portals, they're source of 90% of problems)

I learned recently about RFC 7710 which specifies a DHCP (v4/v6) and RA option for "You're on a captive portal, here's the website you should visit before you get access": https://tools.ietf.org/html/rfc7710

Do any of the major implementations of captive portals support it?

Not that I know. My pfSense firewall doesn't have it (IIRC), so my guess would be that poorly maintained router boxes in a hotel basement definitely don't have it.

I'm not sure if the various DHCP clients communicate this properly to the OS or browser even (I wouldn't know how to query for it on Linux)

If you're using NetworkManager you can get DHCP options by being mildly angry at the D-Bus API:

    $ python3
    >>> import dbus
    >>> bus = dbus.SystemBus()
    >>> nm = bus.get_object("org.freedesktop.NetworkManager", "/org/freedesktop/NetworkManager")
    >>> conn = bus.get_object("org.freedesktop.NetworkManager", nm.Get("org.freedesktop.NetworkManager", "PrimaryConnection", dbus_interface="org.freedesktop.DBus.Properties"))
    >>> dhcp = bus.get_object("org.freedesktop.NetworkManager", conn.Get("org.freedesktop.NetworkManager.Connection.Active", "Dhcp4Config", dbus_interface="org.freedesktop.DBus.Properties"))
    >>> options = dhcp.Get("org.freedesktop.NetworkManager.DHCP4Config", "Options", dbus_interface="org.freedesktop.DBus.Properties")
    >>> str(options["subnet_mask"])
    '255.255.255.240'

I guess you can parse /var/lib/dhcp/dhclient.*.leases otherwise?

RFC 7710 is only a proposed standard.

It has been implemented on a few captive portal solutions[1] but as far as I know it is not understood by any client software.

[1] https://github.com/coova/coova-chilli/pull/274

RFCs are never anything other than proposed standards, or informational documents. There is no point at which an RFC becomes a “recommended standard” or some such thing.

All internet standards, from IP to HTTP, are proposed standards, it doesn’t actually mean anything about whether they’re generally implemented or not.

Actually, they do become standards:

https://www.rfc-editor.org/standards#IS

OH yeah, that started happening recently, I forgot about that.

For reference: https://en.wikipedia.org/wiki/Robustness_principle

"TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others." -- Jon Postel

If more software would take an apostel stand, I feel we would have net fewer interoperability problems.

By that you mean if more software was more strict about what it accepted instead of being liberal about it?

Yes, that.

Reply on news.ycombinator.com