Someone did not grant me a certificate. They simply signed my public key, certifying that they believe that my public key belongs to me. Whether you choose to believe them or not is immaterial. No one is able to make my security WORSE by signing my public key -- that is pretty much the basis of public key cryptography.
(TLS is broken in that it only allows one entity to sign a given key in a certificate. It is incredible that no one has fixed that yet.)
There is a way to grade. If you want actual validation, you need an extended validation certificate.
Any other type of certificate is just a way to scam you out of your money -- they do not verify anything except the fact that you aren't piss-poor. If you think a car charge provides any verification, I give you How to use prepaid debit cards.
If anything, it should be forbidden to charge money for a certificate that isn't extended validation. However, with Let's Encrypt available, the market hopefully sorts it out.
I generate my own key and use letsencrypt to certify it. The key does not leave my server.
The feds can force any number of certificate authorities to generate a certificate that matches mine, with a new private key. They can do exactly the same if I had a self-signed certificate.
They cannot, without doing a targeted attack and breaking into my server, get the actual private key that my site uses. Again, precisely the same as a self-signed certificate.
There is no security advantage to using a self-signed certificate.
If it gets that cold regularly, you use ground-source heat pumps instead. Preferably centralized so you can supply to dense buildings as well. Heat the pipes in summer with solar collectors, so you don't freeze everything after a few years. Sea water is a good option too, if you happen to be situated near the ocean.
It is EXACTLY like going to GSM. Because precisely going to GSM is a major part of it -- ERTMS runs on pretend-circuit-coupled data with GSM (except lower frequency) at the physical layer. Unfortunately there is not enough bandwidth in the allocated spectrum to provide each train at a decent-sized station with one circuit, like the standard requires.
You CAN try to do ERTMS-over-something-vaguely-modern, likely the already obsolete 3G, but that means packet switching which again means unpredictable latency and retransmissions. This is pretty much a solved problem today, but that does not help existing standards.
Denmark is effectively going to invent a Denmark-only version of ERTMS-over-3G to solve this. It is obviously possible that the ERTMS will, perhaps around 2030, get around to blessing that solution as the proper way to do it. In all likelihood the finished ERTMS-over-packet-switching will be on 4G or 5G though, and Denmark will be left with national almost-ERTMS.
The process doing the probing gets the GP faults. It's relying on the fact that even though the accesses fault they still affect the cache. So you could clean up that in the GP fault handler before you return to the process, do a context switch or execute any untrusted code.
You cannot clean it up in the GP fault handler because the hardware thread running at the same time can detect the cache changes before you clean up.
Your solution only works in the single-core single-socket non-threaded case, and most single-core single-socket non-threaded CPUs today do not do speculative execution. Besides, AMD has proven that there is very little performance loss from simply doing the access check properly while speculating. Meltdown is simply not a problem if the chip designer is competent.
You are focusing on fixing the easy case. The hard case, Spectre, is when the speculative execution does not cross a privilege boundary.
Seems like there are two options. One is to do privilege checks before speculative code is executed. Another would be roll back the state of the cache on a protection fault.
The later one appeals actually. In a GP fault handler you could just invalidate the cache line to foil step 7. And you don't need to slow down the common case where speculative execution doesn't execute code which causes a GP fault.
That should work great on uniprocessor single-threaded. However it should be possible to let another core or hardware thread watch whether the cache line gets locked by carefully timing access, and that probably gives the adversary some of the same information. By the time the cache line is invalidated, the adversary already got what they wanted.
Even if I'm wrong and this attack is infeasible, you have only prevented Meltdown, not Spectre.
Spectre hits you when you try to execute untrusted code such as JavaScript in a VM. The VM runs at the same privilege level as the untrusted code, so the CPU does not have any protection boundaries to stop it from speculatively executing into the wrong area. There will be no protection fault, the CPU will just realize that oops the speculation was wrong and do the unwind. You will have to extend your proposal to do cache invalidation on all unwinds, not just protection faults.
I also propose that you arent very knowledgeable about anything dealing with physics but amazingly you somehow are pretending to think you are smart enough to form cogent valid arguments. You arent. You know it. Dishonesty. Thats you.
Way to go. Very impressive. You totally got me there with your well-reasoned arguments.
How do you propose keeping the foils in one orbit? Also, with global warming you don't generally care too much about cooling the equator, it's the poles that you need to keep cool.
Dodging is completely impractical. You can dodge once a month maybe, if you want to have any reasonable longevity for your satellite. Dodging every hour makes you run out of fuel in no time.
Also, you are proposing 100 trillion pieces of foil. Dealing with a million pieces would be a pain, and that's 8 orders of magnitude fewer.
I bloody well did read the memo. I started it, being on the side of the oppressed geek who is misunderstood by his coworkers. When I had finished the whole steaming pile, whatever sympathy I had for Damore had evaporated.
I will keep repeating this: Asshat is not a protected class, nor should it be.
I am unfortunately only too aware of ERTMS. The wonderful new system that is unable to cope with, wait for it, stations. But I get it, without stations there'll be no passengers, and without passengers the trains are going to run much more smoothly and scheduling could be made so much more rational.
I interpreted it like many people did that Damore was being a plonker.
This. The criticism that "you didn't read the memo" is just too easy. I've read the memo. I've read the Unabomber manifesto. I've read the Anarchist Handbook. I've attempted to read Das Kapital in German, but I must admit I got bored.
It is entirely possible that Damore believed that he offered suggestions for getting more women into the field. However, his suggestions were based on wrong beliefs about women, and he didn't even try to provide evidence for his sexist views.
Frankly I'd rather make an attempt at finishing Das Kapital rather than wade through that memo again.
Just to make it more fun, while Sweden and Norway and Germany are on 16.7Hz electric rail, Denmark is on standard 50Hz... While you are right that 50Hz is the sensible standard, from a pragmatic perspective it would have been better for Denmark to be on 16.7Hz.
The problem is mostly solved by running diesel trains under the overhead wires. There ARE dual-standard trains like Öresundstoget though.
Much fun is had with the difference in train signals between the various countries, which will get even more fun as Denmark is trying to upgrade to purely electronic signals.
That is not a rebuttal. What I said is true -- refining petrol requires electricity, and the electricity required to refine petrol to go one mile can just about propel an electric car one mile.
Most transformers you see on poles are designed to cool down at night when usage goes down
Seriously? I would love to hear more about that. It seems highly unlikely that something which handles the heat of day with load from air conditioning should struggle with cooling at night. In areas where air conditioning is unnecessary, cooling is probably not a problem at all.
It is trivial to distinguish between random noise and malware in TLS. Just look at packet sizes and timing.
Even worse, if the adversary has access to the same static web pages, it can't be much trouble to detect which pages the victim is trying to access.
It is ridiculous that neither IPSEC nor TLS do anything to mitigate against that type of attacks. The least they could do was to put everything into predictable full-MTU packets as far as possible. The only tunnelling protocol that attempts anything like that is SEAL, as far as I know. And no one implements SEAL (possibly because the author seems a bit abrasive).
Slashdot Mirror
I love the fact that they include "pricing" on the SpaceX website, like your just buying a refrigerator...
I clicked the shop button, but I couldn't add one to my shopping basket.
Someone did not grant me a certificate. They simply signed my public key, certifying that they believe that my public key belongs to me. Whether you choose to believe them or not is immaterial. No one is able to make my security WORSE by signing my public key -- that is pretty much the basis of public key cryptography.
(TLS is broken in that it only allows one entity to sign a given key in a certificate. It is incredible that no one has fixed that yet.)
So you do 500 tests before you spawn a new process...
Even if this pseudo-fix actually worked, it would only fix Meltdown and not Spectre.
There is a way to grade. If you want actual validation, you need an extended validation certificate.
Any other type of certificate is just a way to scam you out of your money -- they do not verify anything except the fact that you aren't piss-poor. If you think a car charge provides any verification, I give you How to use prepaid debit cards.
If anything, it should be forbidden to charge money for a certificate that isn't extended validation. However, with Let's Encrypt available, the market hopefully sorts it out.
I generate my own key and use letsencrypt to certify it. The key does not leave my server.
The feds can force any number of certificate authorities to generate a certificate that matches mine, with a new private key. They can do exactly the same if I had a self-signed certificate.
They cannot, without doing a targeted attack and breaking into my server, get the actual private key that my site uses. Again, precisely the same as a self-signed certificate.
There is no security advantage to using a self-signed certificate.
The challenge is that you might still be able to get 1000% returns before it pops. And shorting it in the hopes of it popping is dangerous.
The market can stay irrational longer than you can stay solvent.
Israel has nukes. Iran may or may not get nukes soon. Pakistan isn't all that far away, they have nukes.
Saudi Arabia is a repressive dictatorship, currently a patron state of USA, but the winds are ever changing.
It makes a lot of sense for the Saudi Arabia to get some nuclear experience. If it even provides a bit of power too, that's icing on the cake.
If it gets that cold regularly, you use ground-source heat pumps instead. Preferably centralized so you can supply to dense buildings as well. Heat the pipes in summer with solar collectors, so you don't freeze everything after a few years. Sea water is a good option too, if you happen to be situated near the ocean.
It is EXACTLY like going to GSM. Because precisely going to GSM is a major part of it -- ERTMS runs on pretend-circuit-coupled data with GSM (except lower frequency) at the physical layer. Unfortunately there is not enough bandwidth in the allocated spectrum to provide each train at a decent-sized station with one circuit, like the standard requires.
You CAN try to do ERTMS-over-something-vaguely-modern, likely the already obsolete 3G, but that means packet switching which again means unpredictable latency and retransmissions. This is pretty much a solved problem today, but that does not help existing standards.
Denmark is effectively going to invent a Denmark-only version of ERTMS-over-3G to solve this. It is obviously possible that the ERTMS will, perhaps around 2030, get around to blessing that solution as the proper way to do it. In all likelihood the finished ERTMS-over-packet-switching will be on 4G or 5G though, and Denmark will be left with national almost-ERTMS.
The process doing the probing gets the GP faults. It's relying on the fact that even though the accesses fault they still affect the cache. So you could clean up that in the GP fault handler before you return to the process, do a context switch or execute any untrusted code.
You cannot clean it up in the GP fault handler because the hardware thread running at the same time can detect the cache changes before you clean up.
Your solution only works in the single-core single-socket non-threaded case, and most single-core single-socket non-threaded CPUs today do not do speculative execution. Besides, AMD has proven that there is very little performance loss from simply doing the access check properly while speculating. Meltdown is simply not a problem if the chip designer is competent.
You are focusing on fixing the easy case. The hard case, Spectre, is when the speculative execution does not cross a privilege boundary.
No. No they have not. Meltdown is an Intel-only thing except possibly for a few exotic ARMs.
Spectre affects everyone.
Seems like there are two options. One is to do privilege checks before speculative code is executed. Another would be roll back the state of the cache on a protection fault.
The later one appeals actually. In a GP fault handler you could just invalidate the cache line to foil step 7. And you don't need to slow down the common case where speculative execution doesn't execute code which causes a GP fault.
That should work great on uniprocessor single-threaded. However it should be possible to let another core or hardware thread watch whether the cache line gets locked by carefully timing access, and that probably gives the adversary some of the same information. By the time the cache line is invalidated, the adversary already got what they wanted.
Even if I'm wrong and this attack is infeasible, you have only prevented Meltdown, not Spectre.
Spectre hits you when you try to execute untrusted code such as JavaScript in a VM. The VM runs at the same privilege level as the untrusted code, so the CPU does not have any protection boundaries to stop it from speculatively executing into the wrong area. There will be no protection fault, the CPU will just realize that oops the speculation was wrong and do the unwind. You will have to extend your proposal to do cache invalidation on all unwinds, not just protection faults.
I also propose that you arent very knowledgeable about anything dealing with physics but amazingly you somehow are pretending to think you are smart enough to form cogent valid arguments. You arent. You know it. Dishonesty. Thats you.
Way to go. Very impressive. You totally got me there with your well-reasoned arguments.
PLONK
How do you propose keeping the foils in one orbit? Also, with global warming you don't generally care too much about cooling the equator, it's the poles that you need to keep cool.
Dodging is completely impractical. You can dodge once a month maybe, if you want to have any reasonable longevity for your satellite. Dodging every hour makes you run out of fuel in no time.
Also, you are proposing 100 trillion pieces of foil. Dealing with a million pieces would be a pain, and that's 8 orders of magnitude fewer.
I bloody well did read the memo. I started it, being on the side of the oppressed geek who is misunderstood by his coworkers. When I had finished the whole steaming pile, whatever sympathy I had for Damore had evaporated.
I will keep repeating this: Asshat is not a protected class, nor should it be.
I am unfortunately only too aware of ERTMS. The wonderful new system that is unable to cope with, wait for it, stations. But I get it, without stations there'll be no passengers, and without passengers the trains are going to run much more smoothly and scheduling could be made so much more rational.
I interpreted it like many people did that Damore was being a plonker.
This. The criticism that "you didn't read the memo" is just too easy. I've read the memo. I've read the Unabomber manifesto. I've read the Anarchist Handbook. I've attempted to read Das Kapital in German, but I must admit I got bored.
It is entirely possible that Damore believed that he offered suggestions for getting more women into the field. However, his suggestions were based on wrong beliefs about women, and he didn't even try to provide evidence for his sexist views.
Frankly I'd rather make an attempt at finishing Das Kapital rather than wade through that memo again.
The actual content of the memo is not sexist, but it is challenging.
I read the memo. From end to end. It is sexist and unsupported by evidence.
If the memo was factual, you'd have a point.
Instead it was a rant about how women are neurotic.
Just to make it more fun, while Sweden and Norway and Germany are on 16.7Hz electric rail, Denmark is on standard 50Hz... While you are right that 50Hz is the sensible standard, from a pragmatic perspective it would have been better for Denmark to be on 16.7Hz.
The problem is mostly solved by running diesel trains under the overhead wires. There ARE dual-standard trains like Öresundstoget though.
Much fun is had with the difference in train signals between the various countries, which will get even more fun as Denmark is trying to upgrade to purely electronic signals.
That is not a rebuttal. What I said is true -- refining petrol requires electricity, and the electricity required to refine petrol to go one mile can just about propel an electric car one mile.
You can just about drive an electric car on the electricity that is used when refining petrol for the same distance in a petrol car...
Most transformers you see on poles are designed to cool down at night when usage goes down
Seriously? I would love to hear more about that. It seems highly unlikely that something which handles the heat of day with load from air conditioning should struggle with cooling at night. In areas where air conditioning is unnecessary, cooling is probably not a problem at all.
It is trivial to distinguish between random noise and malware in TLS. Just look at packet sizes and timing.
Even worse, if the adversary has access to the same static web pages, it can't be much trouble to detect which pages the victim is trying to access.
It is ridiculous that neither IPSEC nor TLS do anything to mitigate against that type of attacks. The least they could do was to put everything into predictable full-MTU packets as far as possible. The only tunnelling protocol that attempts anything like that is SEAL, as far as I know. And no one implements SEAL (possibly because the author seems a bit abrasive).
Pentium-branded chips are being sold at this time, so that is not a very helpful distinction.