The Internet Is Dying! (Nonsense)
The Market Ticker - Commentary on The Capital Markets
Logging in or registering will improve your experience here
Main Navigation
Display list of topics
Sarah's Resources You Should See
Sarah's Blog Buy Sarah's Pictures
Full-Text Search & Archives
Legal Disclaimer

The content on this site is provided without any warranty, express or implied. All opinions expressed on this site are those of the author and may contain errors or omissions.

NO MATERIAL HERE CONSTITUTES "INVESTMENT ADVICE" NOR IS IT A RECOMMENDATION TO BUY OR SELL ANY FINANCIAL INSTRUMENT, INCLUDING BUT NOT LIMITED TO STOCKS, OPTIONS, BONDS OR FUTURES.

The author may have a position in any company or security mentioned herein. Actions you undertake as a consequence of any analysis, opinion or advertisement on this site are your sole responsibility.

Market charts, when present, used with permission of TD Ameritrade/ThinkOrSwim Inc. Neither TD Ameritrade or ThinkOrSwim have reviewed, approved or disapproved any content herein.

The Market Ticker content may be sent unmodified to lawmakers via print or electronic means or excerpted online for non-commercial purposes provided full attribution is given and the original article source is linked to. Please contact Karl Denninger for reprint permission in other media, to republish full articles, or for any commercial use (which includes any site where advertising is displayed.)

Submissions or tips on matters of economic or political interest may be sent "over the transom" to The Editor at any time. To be considered for publication your submission must include full and correct contact information and be related to an economic or political matter of the day. All submissions become the property of The Market Ticker.

Considering sending spam? Read this first.

2018-10-13 09:55 by Karl Denninger
in Technology , 126 references Ignore this thread
The Internet Is Dying! (Nonsense)
[Comments enabled]

The breathless headlines of the Internet being "screwed up" have been everywhere the last couple of days.

But... it hasn't happened.  And won't.

Here's what's going on.

Back in the day (read: when I was running MCSNet) there were a handful of attacks leveled at the "root" of the DNS services.  DNS is what turns a name (e.g. "market-ticker.org") into an IP address (20.21.22.23 or 2612:8827:810f:7c01:230c:48fe:fe9f:1d6 for Ipv6).

Now the former "dotted-quad" might be able to be remembered, but for most web addresses it's not unique!  That is, if there is more than one web property on a given computer it is utterly common for them to share an IP address.  This works because the web server software looks at the headers of the request and figures out which files to serve.  A similar protocol called "SNI" makes this operable even where "https" is used as it allows the selection of the proper encryption setup (and, by the way, is why https does not obscure what web addresses you view -- just the page contents.)

When you get an Internet connection established one of the things you ask your service provider for (automatically) is a set of "DNS resolvers."  These are usually provided in what is called "DHCP" as part of giving you an address.  Google (among many others) run public resolvers if you don't have them handed to you by your internet provider or simply wish to hard-code them instead -- Google's, for example, is on "8.8.8.8" (easy to remember, eh, although I think they should have obtained and used "6.6.6.6" smiley given the firm's evilness.)

At an infrastructure level it looks backwards, so for example:

.

.ORG   --  .NET  -- .COM (and so on)

MARKET-TICKER.ORG

It's like a tree, basically.  So if you want to look up "market-ticker.org" you first must know where "root" is, and ask "root" (".") for the servers that handle ".org", and then ask one of those servers for the servers that handle "market-ticker" under .org.

All of this data has a "cache time" that the owner of same can set.  The root sets long cache times, the "top level domain" holders (e.g. "ORG") set pretty long ones and the servers for individual domains can set whatever they want (most use one day.)  This is important because it's inefficient to keep asking the same server for the same thing over and over again, so once you have the data if it doesn't change often why keep going back for the same answer?

At the "root" there is a literal flat file that is distributed; if you wish to run a public (or private) DNS server you must have that file containing the location of "." The people who run root servers mostly are funded by IANA although there are some privately-funded examples and they're reasonably-well distributed around the world.  These root servers are critical infrastructure because without them you can't resolve anything!  The good news is that there are a decent number of them and they're spread around; even if the world got nuked tomorrow there would likely be several that would survive.

So let's say you want to screw with people.  Well, one of the best ways to really do it would be to "poison" people's idea of where the roots are -- and point them at corrupted roots instead that hold your data instead of the true data.

DNS (for ordinary requests) runs over what is called "UDP", which is a connectionless protocol.  In other words you send a packet out and some time later a response comes back.  There is no "handshake" established first before data flows.  This is very efficient and since most DNS queries and replies are small but a huge number of people make them and expect replies this is the best option (the other being "TCP", which does handshake first before data flows.)  TCP is used to transfer zones (e.g. if you have multiple servers for "market-ticker.org" they have to synchronize between them; that file may be large, and TCP is usually used for that.)

The problem is if I am asking "root" for an address (e.g. "where is .ORG?") between the time I send the request and the root server sends the reply a "bad guy" could theoretically respond with a tampered packet that claims to have come from the root and I'd believe it because the connection is stateless.  In fact it's trivial to do that and during the 1990s there were a handful of people who did exactly that for malicious purposes.  While this isn't catastrophic it's a serious pain in the ass because until the time of the cached data expires or someone manually flushes it the bad data will be believed and used.  The only fact that makes this sort of attack a serious pain in the ass rather than a "sky is falling" sort of event is that the cache times, which are long at the root and top level zones, mean that requests to them are relatively (from the perspective of any particular user) infrequent and you have to hit that little time window with the forged reply.  This means that unless the "bad guy" has inside access (and thus knows exactly when to send it because he can see the request) he has to "spray" bogus replies at a very high rate on a continuous basis to have any reasonable hope of screwing people and that means the person doing it can be easily traced and caught.

For ordinary things (e.g. reading my blog) an attack like this is highly annoying.  For financial matters it's a different issue entirely in that it allows impersonation of people by someone.  Pulling this sort of attack off successfully isn't exactly trivial but it's also not rocket science, and after it was demonstrated a few times (in at least one instance I'm aware of the person who did it in the '90s was caught and the government went after them hard) the DNS folks decided it was important enough to put a stop to it.

So how do you stop it?

You encrypt the data using a public/private key pair and since the imposter doesn't have the private key necessary to sign the response his tampered packets are now worthless provided the person running the DNS resolver is checking signatures or the end-client performing the lookup verifies the chain.

So now the root zone has encryption keys of trust.  The zone signs the .ORG replies.  .ORG signs the replies that tell you where market-ticker.org is.  And, if I want to, I can set up DNSSEC (encrypted DNS) for market-ticker.org.

I can thus "chase" that chain of signatures and verify them using the public keys, which are published in the zone response itself.  Only the holder of the domain or component of it has the private key.  If the signature is present but no good then I know not to trust the answer.

Now occasionally the root should (or must) update their signing keys.  This is what people are talking about; the root keys were updated to use a higher-security cryptographic option.  If your resolver did not update its public set of root keys then you'd get this:

[karl@NewFS ~]$ drill -S market-ticker.org
;; Number of trusted keys: 1
;; Chasing: market-ticker.org. A

DNSSEC Trust tree:
market-ticker.org. (A)
|---market-ticker.org. (DNSKEY keytag: 48556 alg: 13 flags: 256)
|---market-ticker.org. (DNSKEY keytag: 20378 alg: 13 flags: 257)
|---market-ticker.org. (DS keytag: 20378 digest type: 2)
| |---org. (DNSKEY keytag: 1862 alg: 7 flags: 256)
| |---org. (DNSKEY keytag: 9795 alg: 7 flags: 257)
| |---org. (DNSKEY keytag: 17883 alg: 7 flags: 257)
| |---org. (DS keytag: 9795 digest type: 1)
| | |---. (DNSKEY keytag: 2134 alg: 8 flags: 256)
| | |---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
| |---org. (DS keytag: 9795 digest type: 2)
| |---. (DNSKEY keytag: 2134 alg: 8 flags: 256)
| |---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
|---market-ticker.org. (DS keytag: 20378 digest type: 1)
|---org. (DNSKEY keytag: 1862 alg: 7 flags: 256)
|---org. (DNSKEY keytag: 9795 alg: 7 flags: 257)
|---org. (DNSKEY keytag: 17883 alg: 7 flags: 257)
|---org. (DS keytag: 9795 digest type: 1)
| |---. (DNSKEY keytag: 2134 alg: 8 flags: 256)
| |---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
|---org. (DS keytag: 9795 digest type: 2)
|---. (DNSKEY keytag: 2134 alg: 8 flags: 256)
|---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
No trusted keys found in tree: first error was: No DNSSEC public key(s)

This does not prevent you from getting the address for market-ticker.org, but it does stop you from trusting it since the root's keys are stale and don't verify against the signature provided.  If the zone name holder (e.g. me in this case) didn't sign the domain anyway then it doesn't matter.  I only sign a few of my domains because the maintenance required on a signed zone is greater and someone getting a warning if I screw it up will assume something serious is wrong.  An example of an unsigned zone I own is:

[\u@NewFS /disk/karl]# drill -S cudasystems.net
;; Number of trusted keys: 2
;; Chasing: cudasystems.net. A


DNSSEC Trust tree:
cudasystems.net. (A)
|---cudasystems.net. (DNSKEY keytag: 18068 alg: 13 flags: 256)
|---cudasystems.net. (DNSKEY keytag: 23809 alg: 13 flags: 257)
No trusted keys found in tree: first error was: No DNSSEC public key(s)
;; Chase failed.

But if the resolver is updated and you chase a signed zone then you get this:

[\u@NewFS /disk/karl]# drill -S market-ticker.org
;; Number of trusted keys: 2
;; Chasing: market-ticker.org. A


DNSSEC Trust tree:
market-ticker.org. (A)
|---market-ticker.org. (DNSKEY keytag: 48556 alg: 13 flags: 256)
|---market-ticker.org. (DNSKEY keytag: 20378 alg: 13 flags: 257)
|---market-ticker.org. (DS keytag: 20378 digest type: 1)
| |---org. (DNSKEY keytag: 1862 alg: 7 flags: 256)
| |---org. (DNSKEY keytag: 9795 alg: 7 flags: 257)
| |---org. (DNSKEY keytag: 17883 alg: 7 flags: 257)
| |---org. (DS keytag: 9795 digest type: 1)
| | |---. (DNSKEY keytag: 2134 alg: 8 flags: 256)
| | |---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
| |---org. (DS keytag: 9795 digest type: 2)
| |---. (DNSKEY keytag: 2134 alg: 8 flags: 256)
| |---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
|---market-ticker.org. (DS keytag: 20378 digest type: 2)
|---org. (DNSKEY keytag: 1862 alg: 7 flags: 256)
|---org. (DNSKEY keytag: 9795 alg: 7 flags: 257)
|---org. (DNSKEY keytag: 17883 alg: 7 flags: 257)
|---org. (DS keytag: 9795 digest type: 1)
| |---. (DNSKEY keytag: 2134 alg: 8 flags: 256)
| |---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
|---org. (DS keytag: 9795 digest type: 2)
|---. (DNSKEY keytag: 2134 alg: 8 flags: 256)
|---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
;; Chase successful

No, the Internet will not stop working if the public resolvers (e.g. at your ISP, or at Google, etc) haven't updated their root zone public key cache -- which by the way is an ordinary maintenance task that is usually done automatically.

Yes, you may get warnings.  In a few cases where people have configured systems for high security (e.g. must use DNSSEC, typically where "https" is involved) you may get either a warning or error from an application.

But those folks who are configured intentionally in a more-secure fashion to avoid the risk of tampering and impersonation (e.g. your bankalso are rather likely to have paid really close attention to this issue and made sure that update worked since it's a literal one-line command to fetch and update those root key cache files.  This also applies to the various ISPs (e.g. Comcast, Cox cable, AT&T, etc) and public "open servers" such as Google's at 8.8.8.8.

In short once again those predicting "oh noooooos!" are full of crap.

Oh, and you should like DNSSEC -- it works quite effectively as a means of verifying where you really do care that you're talking to the computer you think you're talking to.

In short SSL (and its derivatives) encrypts the contents of your conversation but it is DNSSEC that provides a cryptographically signed chain of responses so your computer can, with reasonable security, believe that the host that it's talking to is actually at the place where the SSL certificate claims it is.

Go to responses (registration required to post)
 

 
Comments.......
User: Not logged on
Login Register Top Blog Top Blog Topics FAQ
User Info The Internet Is Dying! (Nonsense) in forum [Market-Ticker]
Mangymutt
Posts: 681
Incept: 2015-05-03

Vancouver WA
Report This As A Bad Post Add To Your Ignored User List
But the internet is screwed up.

Security comes at the coast of convenience. People especially those on social media want what they want and they want it NOW!!

People use open wifi, people use their cards in all kinds of unsecured locations and people even use their phones not only to house every bit of personal data but also to pay for things.

When people use their computing devises in public they give up security.

Will the internet die?

Only if society collapses.

Will and are there people who will lose A LOT because of the internet?

You bet.

Granted it is becoming more and more difficult to function in American society without having an internet connection. But security of ones personal belongs is theirs to carry.

If someone does not want to put their personal belongs at risk, they need to understand how easily and willingly they make themselves available to the world.
Login Register Top Blog Top Blog Topics FAQ