Yelp knew when they quit paying Yelp to show the reviews accurately.
Yelp knew when they quit paying Yelp to show the reviews accurately.
If Microsoft released an update that required two key presses to fix and some moron claimed in the headline that it "bricked" computers, we'd have chorus of people saying "the author is an idiot. That's not bricked.". I imagine we'll get the same response today.
It's like most of MD Solar's submissions. There may be a kernel of truth somewhere in them, but they are so wildly exaggerated that the appropriate response is an outpouring of derision for the misleading articles and headlines, not hunting for so hint of something kinda true among the bullshit.
> Looks like it's time to somehow wrap that handshake before moving onto the "I'd like to talk to XYZ site" and adopting that one's certificate.
I guess I wasn't clear about that point in my post. The thing that selects which certificate (which site) IS a man-in-the-middle. So you can't do that while protecting from man-in-the-middle.
Perhaps the best you can do is through some other, out-of-band secure channel, publish a list which men in the middle are allowed. So you'd have a DNS record (DNSSEC signed) saying "traffic to PayPal.com may be intercepted by webserver47474.rackspace.com".
Note DNSSEC doesn't hide your DNS requests, it only authenticates the replies.
> a "password in a file" would be the private key, but even that isn't really a good comparison, because you never transmit your private key
Since at least the 1980s (Kerberos) and dial-up modems used CHAP in 1996, you can authenticate via a password without transmitting the password.
There are even better algorithms that use passwords, without transmitting or storing them on the server. For example, the server can store a salted bcrypt of the password. Upon login, the server generates a random number (the challenge) and sends that to the client, along with the salt the server has chosen for this user. The client then computes and sends:
H(H(Hs(password, salt)), challenge) xor Hs(password, salt)
The server can verify that without having the password transmitted, or stored on the server.
You would be correct to say that *sending plaintext passwords over the network (1970s style)* is much less secure than public keys. You can certainly use passwords without sending them over the network, though - that issue has been solved for decades.
> Plus, even shitty private keys (1024 bits) are way stronger, entropy-wise, than a password so there's that, too.
Much like a LONG password (pass sentence).
Or are least they figured they may as well patch it. Easy patch.
What bothers me the more than the overflow in parsing a malicious EK cert is that they CAN patch it, that a BIOS / UEFI update touches this code. Presumably if a BIOS update can fix it, a malicious bios update can *create* at least a similar problem, and probably a significantly worse variation. Of course we already knew a malicious BIOS would be bad, but I wouldn't expect it to touch that code.
That's a logical thing to think. Not quite right though.
The reason you couldn't have more than ssl site on an IP was that the server has to include its certificate in the Server Ello, the first message sent by the server. The client has to validate the certificate (and therefore the server) before it shares encryption keys with some otherwise unknown actor out on the internet somewhere. The certificate has to be validated WAY before the Host: header is sent, so the server had no way of choosing between different certificates for different sites on the same IP.
About ten or twelve years ago we introduced Server Name Indication to solve that problem. With SNI, in the very first message of the TLS handshake (ClientHello) the client says "Hello I'd like to speak to eBay.com, and I can use the following encryption algorithms". That's the FIRST message sent, way before encryption is set up. The server might not even host the site anymore and the client is still going to send out, in plain text "I'm connecting to Lolitas.com", because it can't even know that's the right server with first announcing which name it's looking for. The encrypted session starts several messages later, after the server knows which site's key to use for encryption, and the client has validated that the cert belongs to that site.
Suppose you could somehow make the ClientHello invisible, so nobody can see the client announcing which site name it is connecting to. Eavesdroppers could STILL see the name because it's in the TLS certificate! You have to send the certificate before you can start an encrypted session based on that cert, so there's no way to hide the name even if you changed the TLS protocol, without completely redesigning it to be a completely different protocol altogether.
> Is the TPM protected from writing? If not, I assume the certificate can be modified/replaced via software.
No, you cannot write directly to TPM nvram from the OS. The spec says the endorsement key is supposed to be permanently burned in at the factory, but some manufacturers instead support CreateEndorsementKeyPair, which asks the TPM to create a key for itself, if it doesn't already have one. If it already has a key, as it should, CreateEndorsementKeyPair does nothing but return an error code.
To put your own malicious endorsement key in the TPM, you'd need to directly access its NVRAM. The most direct way to do that would be to pull out your scanning electron microscope and connect to the nvram traces on the chip. If some *other* vulnerability allowed full write access to TPM NVRAM, that would be a game changer.
Yes, installing an EK cert requires pre-boot access.
You don't know what a buffer overflow, TPM, or attestation certificate are, do you?
I'd like to find the opposite - something solid enough to be self-supporting at least, until it softens greatly on impact. It's easy enough to find thick liquids that thin under stress (ketchup being one example), but I want it *solid* until it's stressed.
So far the closest I have is floral foam, which crushes easily into a powder.
Decades ago, before he got into politics, I studied Trump quite a bit. I read all his books, which explained his thinking although ghost writers wrote the words. I've paid more attention since he started wading into politics and making some outrageous statements. He's not that complicated and his major ideas have been written about extensively.
When he makes public statements, keep in mind he LOVES to get press, he craves publicity. Good press or bad press it doesn't much matter, he just wants to be in the news. Raising his profile both advances his business / agenda and simply feels good for him. There were 16 Republican candidates who were generally more classically qualified than him, yet he got all the attention, and that's a big part of what won him the presidency.
He also loves HUGE, and spectacular! People joke about him always saying everything is going to be "yuge", the biggest, the best ever, and that joke is because he actually does that. He builds hotels huge, with gold plated stuff everywhere. That's his personality. He loves the biggest, the best, going to extremes - and then emphasizing the "yuge" in his PR.
There are a few other things, but those two go a long way to understanding whatever Trump says publicly.
At 60 miles, the air pressure is very low. That doesn't mean you have "limitless time" or any of that. In order to orbit at that altitude, you'd need to be traveling at 20KM/ s or so. The Falcon is only going 500 m/s at that altitude. It would need to be going about 40 times as fast for what you said to make sense.
Which one is closer depends very much on how long after launch we're talking about. It's a space rocket - toward the end of the flight is very much nearer space than it is to the ground. In fact the Falcon may go twice as high as GPS satellites.
Prior to iOS 11, you had to hold down the quote button to get the option to use "smart quotes". Now that those are the default, holding the button down may give the option to use standard quotes. If not, one can turn them off entirely in Settings > General > Keyboards.
The questioner said "We do a lot of I/O". If you do io 512 bytes at a time, this may be noticeable. But that was a poor choice to begin with. 8192 bytes can be a lot faster, even without this issue, and even more so now. Each disk read is a call into kernel space. To minimize the number of calls, grab more data each time.
Try different values and benchmark. It can make a big difference.
A couple thousand people in the US have the disease. I guesstimated that half of those might pay full price for the treatment (via their insurance company). The pharmacuetical company has already announced their own subsidies, so some will get the treatment at less than full cost. Some won't be good candidates for whatever reason, and some may decide to stay away from this genetic therapy stuff for now.
What is now proved was once only imagin'd. -- William Blake