The Market Ticker
Commentary on The Capital Markets- Category [Technology]
Logging in or registering will improve your experience here
Main Navigation
MUST-READ Selection(s):
There Can Be NO Compromise On Data

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
[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.

View this entry with comments (opens new window)
 

2018-10-06 07:15 by Karl Denninger
in Technology , 153 references
[Comments enabled]  

This has to take the cake as the most-outrageous scaremongering line of crap I've seen in years.

 

Put the bong down dude.

Seriously.

Conflating the two systems -- E911, which is part of all modern phones -- and what is called "WEA" or Cell Broadcast is beyond stupid.  In fact it borders on insanity -- or paranoid delusions.

My knowledge on this is quite-detailed since I ported AOSP (Android, bare) to the T-Mobile Valiant back in the day when that was an actual phone and people knew what it was.  I ran smack-bang into it with the RIL (closed-source software that runs the radios on a phone) making callbacks into the Android code when 911 was dialed for which there was zero documentation.  The RIL was trying to request location (presumably from the GPS) but since there was no documentation as to what it wanted I couldn't respond correctly to the callback and the RIL was refusing to enable the voice channel until it got the response!  The result was that a 911 call with custom (other than "stock") firmware left you unable to be heard by the 911 operator who would of course then assume you were incapacitated and send God and Everyone out!  Bad, bad and BAD!

This was when E911 was new and thus there were no examples around to look at and as such while I liked my custom-baked firmware you had to be VERY aware that 911 was basically non-functional on the device.

When you dial 911 that callback is made which requests your position; that is then transmitted to the E911 center.  This has been true for five+ years now, and is basically universal in the United States.  There is no issue with turning on your microphone or speaker in that situation, nor with the GPS, since you dialed 911 and the entire point of dialing 911 is for emergency services to find and assist you.

Cell Broadcast works completely differently.  In other nations it is frequently used for other things (e.g. local weather) because it's extremely efficient.  It's a multicast system and sends an index and category on a regular basis when the cell system is talking to your device (very small and thus efficient) and if you've not seen at least "X" (the index) then your device winds up getting the "new" broadcasts.  This is inherently a one-way communication; it's very similar to how SMS works but is not targeted toward only one device as is an SMS message.  Indeed on modern Android phones the SMS app is what handles these messages, and it caches the most-recent one.

In addition to the "Presidential Alerts" it is what's used for tornado warnings (and Amber alerts as well) and can be targeted as closely as a single cell tower, which is very useful -- you won't get a tornado warning for half a state away, but you will get the one for your local area when the tornado is about to rip up your house.  This is a good thing, incidentally.

Contrary to popular belief you can basically disable it.  There's a registered listener called the "Cell Broadcast Receiver" (in Android devices at least) that is where these get directed to by the operating system.

 

Now you can (at least on my device) revoke its permissions (to SMS), which will at least stop the caching of the latest message (since the receiver won't be able to send it onward to the SMS application itself.)  It can be force-stopped but not disabled, at least on the ROM I have on my Essential PH-1.  If you load your own ROM then you could omit it, or root your device and remove (or disable) the app at which point the receiver would not exist.  But the point is this -- it has no permissions other than SMS -- no location, microphone, camera or storage permission -- and thus cannot get at those other things.

It's a broadcast receiver and that's how it's registered with the system; this is what receives and pops up the message on your device.

It would also be completely stupid to have a cell broadcast result in responses from each device.  The cell network can only handle a small percentage of the terminals (phones) transmitting at one time.  Even if you are all "sitting on your phone playing with Facesucker" you are only actually transmitting every now and then; the rest of the time you're reading or scrolling and your device is transmitting nothing.

A request to every device in the network to transmit position and speech or worse, video at once would instantly overload the network and nothing would get through.  It would result in an immediate overcommit of thousands (if not tens of thousands or more) of percent of capacity, exactly as occurs when everyone tries to use the phone at once immediately after an earthquake or other event.  Even though the system is not physically damaged basically nobody gets usable service because the capacity is so badly exceeded by demand that nothing gets through to the intended recipient.

This, incidentally, is why the cell carriers tell you to use SMS instead of a call or data during a serious event like a Hurricane.  An SMS transmission is tiny (140 characters max) and can queue without harm, so it is far more-likely to get through -- even if slowly -- during severe congestion than a voice call or data connection.

Finally, if a carrier wants to know where you are they don't need your phone's GPS.  If your phone can see two towers they can pinpoint you on a vector (a line) using nothing more than propagation delay within a few hundred feet.  If it can see three or more towers they can pinpoint you in a 2d space, again, within a few hundred feet and if your device can see 4 or more they can pinpoint you within a 3d space (not that altitude matters much if you're on the ground!)  No cooperation with your device other than it being on and in service is required for this.  But again, nobody in their right mind would try to do that for every device all at once because the network is simply not designed to be able to handle that sort of load.

There is plenty of spying that goes on with the device in your pocket but this specific claim is that of a fruitcake.  No, the transmission of that "Presidential Alert" did not result in your phone sending back its location and turning on your microphone and camera so they can see you wanking off to the Dallas Cowboy's cheerleading squad.

View this entry with comments (opens new window)
 

2018-10-05 07:55 by Karl Denninger
in Technology , 110 references
[Comments enabled]  

Amazon of course has denied that they had "issues" with Supermicro boards.

I don't believe them.

Incidentally Supermicro has, through either intentional malfeasance or simple laziness, refused to fix a serious problem with some of their earlier boards.  I own two of them -- and their IPMI/BMC implementation refuses to accept a modern, user-issued (e.g. "formal") 2048-bit RSA certificate and key.

It claims it has loaded but when the unit is restarted to use it... it's gone.

The "self-generated" certificate works, but is only 1024 bits, which is inadequate.  And even a user-generated 1024-bit certificate won't "stick."

These boards are now considered "EOL" and there's no further updates available for them.  As a result I have mine behind a DMZ that cannot get either in or out with a second machine between them and anything else to which I must sign into (using a strong certificate) and manually establish a tunnel before I can connect to them remotely.  This has always been the case as I have never been happy with their so-called "security."

As far as Amazon and Apple, among others, denying they were "victimized" by these boards, well, let me point out that there's no penalty for lying in this country anymore, those statements were not made under oath and even if they were there is a zero risk of any of their executives being prosecuted or jailed.  Further, AWS would be utterly decimated were it exposed that the management interface to these servers was compromised.

Well folks, it was compromised, and if you have any sort of brainpower available you damn well ought to stop fooling yourself when it comes to so-called "cloud" computing -- it isn't secure, it will never be secure and neither is your data if it's in such an environment.

Oh, and that's exactly how these big firms and government like it.

View this entry with comments (opens new window)
 

2018-09-30 09:10 by Karl Denninger
in Technology , 140 references
[Comments enabled]  

This is an interesting essay....

Programs can’t work for years without reboots anymore. Sometimes even days are too much to ask. Random stuff happens and nobody knows why.

What’s worse, nobody has time to stop and figure out what happened. Why bother if you can always buy your way out of it. Spin another AWS instance. Restart process. Drop and restore the whole database. Write a watchdog that will restart your broken app every 20 minutes. Include same resources multiple times, zip and ship. Move fast, don’t fix.

That is not engineering. That’s just lazy programming. Engineering is understanding performance, structure, limits of what you build, deeply. Combining poorly written stuff with more poorly written stuff goes strictly against that. To progress, we need to understand what and why are we doing.

The author misses why it has happened.

It started with the so-called "colleges."

In the early 1980s you had to learn Macro.  On something.  In other words, assembler.

Bare-metal coding.  I started figuring that out in the late 70s, as a kid.  On a TRS-80 Model I.  Then on my own, a Model III.  By the time I got into that college they had started with Pascal, RPG and (gaaak!) Cobol.

Yes, I can probably still write in any of those.

But then I got to Macro, which was commonly through of as a "weed-out" class.  It should have been too, except in this case it was "taught" by a PhD in..... mathematics, who couldn't program his way out of a paper bag.  A few nights in the computer lab with the instruction manual for the machine and, having written in assembler on a couple of CPUs prior (including the Z80), which included writing interrupt handlers to do real-time stuff, I was able to write compact, tight, efficient code -- in Macro.  I turned in one such assignment and got an "F" on it because I had used instructions that hadn't been gone over in class yet.

Needless to say I protested.  And then said "professor" claimed, in front of the class, that a particular tactic and instruction I had used didn't work the way it did -- never mind the actual instruction set manual for said machine said I was right, he was wrong, and my code using it ran.

It wasn't long after that I left college with a big fat upturned middle finger in their direction.  But the rot had only just begun.

Now it's beyond terminal.

10000 98735 1 0 27 0 25608 10064 select Ss - 99:55.81 hd-mcp

That's HomeDaemon-MCP from a "ps" command. .It occupies about 10 megabytes of RAM, including allocated data structures in RAM, and has a full working set of code (that is, everything about it) of 25.6 megabytes; an utterly-huge percentage of which is the OpenSSL libraries against which it is linked. The actual stripped executable (no symbols) that is running totals a grand 464,000 bytes on disk.  The non-encryption supported version totals 302,000 bytes.

Not megabytes, not gigabytes, bytes.

Said code consumes less than 20-30% of one (out of four) CPUs on said box that runs a stunning 600mhz clockrate (in other words, less CPU than a modern cellphone) while answering to multiple client applications and browsers.  It contains an internal web server that speaks http and https; it does not call or use something like Apache to perform interaction with people.  It talks to multiple external devices including a Z-wave stick, an X10 interface (CM11), GPIO and analog I2c interfaces and, of course, the network.  It's extremely fast as you might expect from being compact, tight code.

Every line of it is written in "C"; there is no "Python", "PHP", Java or any such similar claptrap.

And it runs for weeks or months -- not days.  Why does it stop running, when it stops running?  The power goes off.

When the power comes back on it starts running again.

But when you put SJWs in charge of "code", when you allow a meritocracy to become an "EEO" lovefest, when you coddle people's fantasies who can't figure out that if you have a penis you're male and a vagina you're female, when you allow people who gin up bull**** to destroy people for fun and profit because their pet peccadillo doesn't find "affirmation", when being female, black, yellow or martian becomes a cudgel to compel people to hire you, not fire you or just look at you even though you suck at coding then you get the hairballs we call Android, so-called "CMS" systems and similar, all written in crap, by crap and which look and function like the bottom of an excrement-filled monkey cage.

That is the source of this problem, when you get down to it, and yet the original author is unwilling -- or unable, as he too is under the same threat as most others in society today -- to call it what it is and burn the individuals and institutions involved to a crisp, rendering everyone involved in both unable to find a job with a title better than "sanitation engineer" from this day forward.

View this entry with comments (opens new window)
 

2018-06-06 16:23 by Karl Denninger
in Technology , 101 references
[Comments enabled]  

Nope, nope and nope.

Quick demo of the lock support in the HomeDaemon-MCP app including immediate notification of all changes (and why/how) along with a demonstration of the 100% effective prevention of the so-called Z-Shave hack from working.

Simply put it is entirely under the controller's choice whether it permits high-power keying for S0 nodes.  For those controllers that have no batteries and no detachable RF stick, which is a design choice, there's not a lot of option.

But for those who follow best practice that has been in place since the very first Z-Wave networks you're 100% immune to this attack unless you insist and intentionally shut off the protection -- even in a world where S2 adoption becomes commonplace (which certainly isn't today but will become more-so over time.)

HomeDaemon-MCP is available for the entity that wishes to make a huge dent in the market with a highly-secure, very fast and fully-capable automation, security and monitoring appliance, whether for embedded sale (e.g. in the homebuilding industry) or as a stand-alone offering.  Look to the right and email me for more information.

View this entry with comments (opens new window)