Nottingham: Internet protocols are changing
The newest change on the horizon is DOH — DNS over HTTP. A significant amount of research has shown that networks commonly use DNS as a means of imposing policy (whether on behalf of the network operator or a greater authority). Circumventing this kind of control with encryption has been discussed for a while, but it has a disadvantage (at least from some standpoints) — it is possible to discriminate it from other traffic; for example, by using its port number to block access. DOH addresses that by piggybacking DNS traffic onto an existing HTTP connection, thereby removing any discriminators."
Posted Dec 12, 2017 17:54 UTC (Tue)
by smurf (subscriber, #17840)
[Link] (4 responses)
Note that there are a couple of stealth protocol implementations which route IP over DNS … allowing us to go full circle.
Posted Dec 13, 2017 9:52 UTC (Wed)
by jezuch (subscriber, #52988)
[Link] (3 responses)
Posted Dec 13, 2017 16:05 UTC (Wed)
by ballombe (subscriber, #9523)
[Link] (1 responses)
Posted Dec 17, 2017 2:02 UTC (Sun)
by scientes (guest, #83068)
[Link]
also Tor goes over port 443 for obvious reasons, and has an identical handshake to firefox
Posted Dec 16, 2017 10:27 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
Posted Dec 12, 2017 17:58 UTC (Tue)
by flussence (guest, #85566)
[Link] (6 responses)
Posted Dec 12, 2017 18:07 UTC (Tue)
by epa (subscriber, #39769)
[Link] (4 responses)
https://{google.com:172.217.23.46:ZLgE36lVHk}/
where the last bit is some cryptographic signature from the original nameserver (so if you trust that nameserver with DNSSEC, you will trust that the new name/address pair seen in the URI is correct). That would reduce round trips still further.
Posted Dec 13, 2017 10:59 UTC (Wed)
by buchanmilne (guest, #42315)
[Link] (3 responses)
Posted Dec 13, 2017 14:21 UTC (Wed)
by epa (subscriber, #39769)
[Link]
I envisaged that if your machine already has a cached IP address for that hostname, you use that as normal. Only if you don't currently have the hostname resolved would you have the option of saving a round trip (or bypassing hostile DNS blocking) by using the address embedded in the URI.
Posted Jan 8, 2018 0:55 UTC (Mon)
by immibis (subscriber, #105511)
[Link] (1 responses)
Posted Jan 18, 2018 2:32 UTC (Thu)
by flussence (guest, #85566)
[Link]
Posted Dec 13, 2017 9:53 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link]
With OCSP stapling when I connect to a server, and it is going to show me the certificate saying "I'm server A" it can staple the OCSP response which says "I, the OCSP server, promise this certificate for server A is still good". It is trivially able to obtain this response because it has the certificate already, and the response is signed, so it doesn't matter how it is delivered [Yet despite this two of the world's most popular web servers can't get this right...]
With CT stapling when I connect to an OCSP server to ask about server A and it's going to provide an OCSP response "I, the OCSP server, promise this certificate for server A is still good" it can also staple the SCT which says "I, a CT log server promise this certificate was logged at a specific moment of time T", it knows the full set of certificates it cares about [that's what OCSP is for] and so it also has all the SCTs for them if it wants. This too is signed and so it doesn't matter how it's delivered [Although details of how exactly we ensure that bogus proofs are detected are still up in the air]
But with "Flussence DNS Stapling" how does this work? What's signed? Who am I connecting to that knows I need this?
The user just typed bimble.example.com into my browser. I want to use "Flussence DNS Stapling" which I've heard is great and will speed things up. What do I do now? I need to start sending a packet immediately. I don't know where to send it, what should I put in it - the "Flussence DNS Stapling" needs to have fast, reliable answers for both those things or it's useless, because in just a few milliseconds a traditional DNS would probably have an answer.
Posted Dec 12, 2017 18:35 UTC (Tue)
by rweikusat2 (subscriber, #117920)
[Link] (41 responses)
Now, the news here is what?
Posted Dec 12, 2017 18:54 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (39 responses)
Posted Dec 12, 2017 19:03 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (19 responses)
If private organisations want to break the internet at the border, that's fine, but ISPs (providers of a public service) should support public protocols. Then all this rubbish wouldn't be needed!
DNS is broken? The reason we can't design a new protocol and fix it, is because the public infrastructure assumes we are using "DNS over port 53" and will break any replacement! Dumb, dumber, and absolutely ********* stupid. :-(
Cheers,
Posted Dec 12, 2017 19:48 UTC (Tue)
by fest3er (guest, #60379)
[Link] (13 responses)
The owner of a private internetwork has the duty to inspect all data that passes through her perimeter firewall and to drop all packets and conns that carry malware whether it enters or leaves her network.
The problem is not what ISPs do. Rather, the problem is that ISPs are not held to be 'common carriers'. They want to lock their captives into using, and paying for, any and all services and advertising the ISPs can dream up. They require users to pay for internet access and bandwidth and they want to force users to pay for the extra bandwidth that all their advertising 'partners' use. Were ISPs common carriers, they would have to provide equal access to all traffic; they would not be allowed to interfere with internet traffic.
The proper solution is to employ host-to-gateway, gateway-to-gateway, and gateway-to-host opportunistic encryption. This would allow owners and operators of private internetworks to detect and drop malware and other traffic that they do not want on their networks without having to jump through hoops imposed by well-meaning but misguided internet mavens.
Posted Dec 12, 2017 20:19 UTC (Tue)
by josh (subscriber, #17465)
[Link] (10 responses)
Those don't solve the problem that end-to-end encryption does, and once you have end-to-end encryption then opportunistic encryption is pointless.
Posted Dec 12, 2017 20:40 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (9 responses)
I always used to describe my then ISP (Demon) as an Internet *ACCESS* Provider because that's what they were - "here's an IP address, here's a physical (dial-up) link, off you go!". Everything else (mail, web server, spam filtering, etc etc) was opt-in.
If ISPs provided the physical infrastructure and packet routing AND THAT WAS ALL, then half of today's problems would go away!!! By all means they can provide extra opt-in services, but stop providing "can't opt out" services that break the system!!!
If "end to end" encryption is an opt-in, great. But don't force it on me, just so's you can fix problems that shouldn't exist!!! (Which also puts banks etc - looking after MY money - into a catch-22 :-(
Cheers,
Posted Dec 12, 2017 21:04 UTC (Tue)
by josh (subscriber, #17465)
[Link] (7 responses)
Posted Dec 14, 2017 2:47 UTC (Thu)
by Garak (guest, #99377)
[Link] (6 responses)
Posted Dec 14, 2017 9:38 UTC (Thu)
by josh (subscriber, #17465)
[Link] (5 responses)
All HTTP should go away in favor of HTTPS. That's not "using encryption blindly", that's a reasonable response to established threat models.
Posted Dec 16, 2017 12:47 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (4 responses)
What about those of us who don't use the web? Or are you saying that the ONLY port in use should be (80)80?
Plus, at the end of the day YOU are DICTATING to ME what I should use. NOT acceptable!
(I may agree with you - I may think https is better than http - but I might think the exact opposite FOR MY USE CASE!)
Cheers,
Posted Dec 16, 2017 17:31 UTC (Sat)
by josh (subscriber, #17465)
[Link] (3 responses)
I never claimed it was. Please stop making up things I haven't said and then yelling at me about them.
> What about those of us who don't use the web?
I never said anything about non-http protocols. I do think that protocols that don't have end-to-end encryption should be carefully evaluated, and many of them should go away as well, but my previous comment *only* talked about http and https.
> Or are you saying that the ONLY port in use should be (80)80?
I never said that. (And in any case, port 80 is the insecure one, so I certainly wouldn't be saying *that*, for multiple reasons.)
You seem to be attempting to force an angry confrontation, and I'm not interested. If you want to use insecure protocols, you can always find ways to do so; if you control the software on both ends, you can have them communicate by any means you wish. The tools and infrastructure that the majority of people use will continue to steer people towards secure protocols more and more strongly, so that the path of least resistance becomes safer. Security is often a usability problem, and I applaud the many people working to make the defaults both more secure and more usable.
Posted Dec 17, 2017 0:49 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (2 responses)
If you actually look, you will see all along that I am merely reacting to other people telling me what I should or should not do. You were telling me I should not be using plain http. Why not? And to be honest I've seen use cases where http is better than https (mostly a large volume of static pages, iirc).
If other people secure their networks with the result that I can't communicate, well, I'll cross that bridge when I come to it. But to give a silly example of "security is a bad thing", would you recommend that everyone keeps their doors locked to keep strangers out? Sounds like a good idea, until you realise that the whole point of a shop is to welcome random strangers ...
(I regularly come across reference to "security theatre" - actions that LOOK like they improve matters, until you actually look carefully and realise that they do very little, or even make matters worse!)
Cheers,
Posted Dec 17, 2017 1:12 UTC (Sun)
by pizza (subscriber, #46)
[Link]
.... during "normal business hours". And said doors will be locked during other times.
You picked a rather poor analogy.
Posted Dec 17, 2017 3:01 UTC (Sun)
by josh (subscriber, #17465)
[Link]
HTTPS is, at this point, down in the noise with respect to computation. You're certainly not going to become CPU-bound serving static pages over HTTPS.
> If other people secure their networks with the result that I can't communicate
What is preventing you from communicating using encryption? You seem to be phrasing your responses as if HTTPS is a non-starter for you.
> (I regularly come across reference to "security theatre" - actions that LOOK like they improve matters, until you actually look carefully and realise that they do very little, or even make matters worse!)
HTTPS is not one of those things, however.
Posted Dec 13, 2017 1:42 UTC (Wed)
by interalia (subscriber, #26615)
[Link]
Posted Dec 12, 2017 22:10 UTC (Tue)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Imposition of a duty to actively MITM every single outbound connection would have some... interesting interactions with various kinds of confidentiality law.
Posted Dec 13, 2017 9:19 UTC (Wed)
by dottedmag (subscriber, #18590)
[Link]
Posted Dec 13, 2017 4:43 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (4 responses)
Yes, the carriers should not block "strange" protocols, but do they really? IME setting up a random GRE tunnel [i.e. not TCP or UDP] just works.
Posted Dec 13, 2017 13:42 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (3 responses)
If the private network doesn't want to receive UDP, that's its decision. If the private network doesn't want outbound DNS queries, that's its decision. If the private network falls over in a heap thanks to stupid decisions, that's its problem.
The problem is when (for example, and this bites me regularly) my private network wants to talk SMTP to your private network, and the public network says "oh no, you can't talk SMTP to anyone but me". (I regularly find myself troubleshooting the aged parent-in-law's laptop, and it would be so much easier to do it in my house except we have different ISPs, so my mail doesn't work there, and his mail doesn't work here.)
Cheers,
Posted Dec 14, 2017 19:59 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (1 responses)
It's easy enough to set up a VPN!
Posted Dec 15, 2017 9:43 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Okay, my mail server should be configured for end-to-end encryption, BUT THAT'S MY DECISION NOT YOURS. And if all the ISPs did was to route traffic, they would neither know nor care.
Saying "it's easy enough to set up a VPN", what, with somebody in Oz I hardly know, to send maybe a couple of emails a month? Whatever for?
If the ISPs merely route packets, then I have control of the borders of my network. If I want to encrypt everything then that's my choice. If I DON'T want to encrypt everything that's my choice. If every protocol DEFAULTS to encrypted, then I can over-ride it if I want. The point is, I CHOOSE.
The problem at present, is that I cannot assume that *legal* packets will make their way across the internet from my private network to someone else's private network, without the "postal" service snooping and throwing away stuff it happens to take a dislike to.
Cheers,
Posted Dec 16, 2017 10:23 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
Please use a real protocol as an example; I mean anything but the SpaM Transfer Protocol.
Posted Dec 12, 2017 19:35 UTC (Tue)
by corbet (editor, #1)
[Link] (5 responses)
Posted Dec 12, 2017 19:44 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
It's more difficult for IoT-type devices, though.
Posted Dec 16, 2017 8:18 UTC (Sat)
by accumulator (guest, #95885)
[Link] (1 responses)
Posted Dec 16, 2017 22:00 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
If the user of the browser is working in a "bank that has regulatory requirements for visibility" then you can take for granted that not just his or her browser but his entire machine is busy running Data Loss Protection and various other keyloggers (in addition to any traffic scanning further in the network)
Posted Dec 12, 2017 19:50 UTC (Tue)
by bbockelm (subscriber, #71069)
[Link]
If it's *my* device, then I don't want you to be able to look at the data! Unfortunately, some of the best tools for analyzing your own network activity do double-duty as tools that spy on my network activity.
This all seems to be a reaction against middleboxes that (rightly or wrongly) want to inspect and/or change traffic they aren't a party to. The link had a fairly interesting example where network middleboxes arguably should have access to traffic: internal to a corporate-owned network (particularly when the enterprise activity is highly regulated as in banking).
Posted Dec 12, 2017 21:52 UTC (Tue)
by ballombe (subscriber, #9523)
[Link]
Posted Dec 13, 2017 21:26 UTC (Wed)
by rweikusat2 (subscriber, #117920)
[Link] (12 responses)
There are other examples were people have a good reason to enforce a usage policy.
Posted Dec 13, 2017 21:36 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
(also, blocking porn is super futile, kids know perfectly well how to work around filters)
Posted Dec 13, 2017 22:05 UTC (Wed)
by rweikusat2 (subscriber, #117920)
[Link] (7 responses)
Beliefs about the "futility" of enforcing applicable laws and/or usage policies are of no technical relevance here: DNS "interference" has legitimate use cases.
Posted Dec 14, 2017 13:07 UTC (Thu)
by nix (subscriber, #2304)
[Link] (6 responses)
Also, humans of a certain age are far more motivated to find the stuff than anyone is likely to be to stop it. This is a race you are bound to lose, with considerable collateral damage being the only outcome.
Posted Dec 21, 2017 21:31 UTC (Thu)
by rweikusat2 (subscriber, #117920)
[Link] (5 responses)
Further, your beliefs about the futility of ... are also irrelevant. There are legitmate uses case for what Google would prefer to be referred as "DNS interference".
As to the "it doesn't work": If it really wouldn't work, why would Google burn money trying to stop it from working?
Posted Dec 21, 2017 22:13 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Posted Dec 21, 2017 22:25 UTC (Thu)
by rweikusat2 (subscriber, #117920)
[Link] (2 responses)
My original statement was that these "internet innovations by Google" would be motivated by making life more difficult for third parties with a good reason to enforce usage policies as enforcement of usage policies would be detrimental to Google revenue. "Parties with a good reason to enforce usage policies" might be "the evil Chineses government" (Google likes talking about that) or "the association of head teachers tasked with preventing porn consumption by minors" (Google likes talking about that much less).
Posted Dec 21, 2017 22:52 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Dec 22, 2017 8:25 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
Posted Jan 4, 2018 11:59 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Google will burn money trying to stop this from working because politicians will cause a PR disaster if they don't appear to do something. "For the chiilldren" is a very effective rallying cry, even when it relates to matters that children don't care about, or that adolescents care very much about and have diametrically opposing views to their parents on.
Posted Dec 16, 2017 21:43 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
Teenagers actively looking for it, probably yes. Youger kids randomly browsing who don't even know what it is, most certainly not.
Posted Dec 16, 2017 21:49 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (1 responses)
Agreed - or subscribe to a *per-endpoint and optional* service offered by your provider.
Posted Dec 17, 2017 8:15 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Dec 16, 2017 22:04 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
Posted Dec 12, 2017 19:24 UTC (Tue)
by bmur (guest, #52954)
[Link]
The biggest danger to internet freedom is the current trend of registrars threatening to take away your domain name for having a contrarian point of view. It recently happened to gab.ai.
Posted Dec 13, 2017 1:26 UTC (Wed)
by gdt (subscriber, #6284)
[Link] (2 responses)
Does technologically placing DNS within HTTP lower the political desire of network owners to manipulate DNS? If removing Google websites is the cost of filtering DNS then that may be a price the Great Firewall of China will pay.
Posted Dec 13, 2017 2:56 UTC (Wed)
by josh (subscriber, #17465)
[Link]
Posted Dec 13, 2017 19:15 UTC (Wed)
by david.a.wheeler (subscriber, #72896)
[Link]
DOH
DOH
DOH
So to avoid that only a single port is used, which then become heavily multiplexed.
DOH
DOH
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
The URI specification should allow the hostname to be given as both IP address and name at the same time.
https://{google.com:172.217.23.46:ZLgE36lVHk}/
where the last bit is some cryptographic signature from the original nameserver (so if you trust that nameserver with DNSSEC, you will trust that the new name/address pair seen in the URI is correct). That would reduce round trips still further.
But now you've made the experience worse for everyone for whom the best Google PoP or Edge PoP (and of course any other CDN) isn't the same as yours.
For example, for me, google.com is one of 6 addresses in 108.177.119/24, but from home it's a totally different range.
For people who live 500ms away from you on a slow-ish link (e.g < 1Mbps), this could be the difference between the internet working, and not working (e.g. Youtube doesn't play, Netflix doesn't work, Google images take forever to load, Android App Updates fail).
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Wol
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Wol
Nottingham: Internet protocols are changing
encryption is a multidimensional spectrum of utilitarian trade-offs
Yes, ISPs shouldn't tamper with your insecure traffic, but you also shouldn't have insecure traffic because malicious people do exist. Yes, postal services shouldn't read your postcards, but you should use envelopes.
Going without envelopes is fine in many situations- opted-in coupon mailings from a restaurant. If envelopes truly had zero cost, sure you'd throw one of those magic ones on even then. But there are costs. Likewise there are costs for encryption. And though there are some popular ubiquitous variants, it is an important part of the ecosystem that there are variants. Some variants are more and less suited to various use-cases and threat models. A common situation would be some kinds of games and entertainment where the utility of shaving latency outweighs the threat models that encryption protects against. And threat models and applications (and thus their specific usage of encryption) evolve over time. It is not good to advise using encryption blindly. People that do probably also haven't given proper consideration to the true contingency trees and cost/benefit full analysis. They probably have bought into an over simplification that "it's encrypted, nothing bad will ever happen". It's way more complex than that.
encryption is a multidimensional spectrum of utilitarian trade-offs
encryption is a multidimensional spectrum of utilitarian trade-offs
Wol
encryption is a multidimensional spectrum of utilitarian trade-offs
encryption is a multidimensional spectrum of utilitarian trade-offs
Wol
encryption is a multidimensional spectrum of utilitarian trade-offs
encryption is a multidimensional spectrum of utilitarian trade-offs
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
The owner of a private internetwork has the duty to inspect all data that passes through her perimeter firewall and to drop all packets and conns that carry malware whether it enters or leaves her network.
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Wol
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Wol
Nottingham: Internet protocols are changing
So if I want to know what my Google apps are sending to the mothership, I shouldn't look?
Spying on data
Spying on data
Spying on data
That said, apps can already hardcode IP addresses or implement their own custom resolvers anyway..
Spying on data
Spying on data
Spying on data
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
So that it won't work at all.
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
As I already wrote: Your unbacked assertion that "I" must be involved in this is both irrelvant and wrong.
Of course I wasn't implying any such thing: 'you' in English can be used to collectively refer to people that do not necessarily include the interlocutor.
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
> Now, the news here is what?
The news is: all this work is done in the open, standardized and can be re-used by anyone or anything outside Google. Say thank you?
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing
Nottingham: Internet protocols are changing