What bugs me about operator overloading is how tediously verbose it can get. For example, say you define operator functions for < and ==. You still have to do <=.
Get a better language.
For instance, in Python, functools.total_ordering will give you all six comparison operators when you give it < and ==. In C++, std::rel_ops will do the same thing. (Admittedly, in the C++ version it isn't on a per-class basis without some work because those are function templates, so you either get them for all classes or none.)
Down at the machine level, the computer does not stupidly require 2 separate comparisons to test Get a better compiler.
Given the code
bool leq_native(int a, int b) {
return a <= b; }
bool leq_or(int a, int b) {
return a < b || a == b; }
GCC at -O1 or -Og or higher and Clang at all optimization levels all produce identical code for the two functions.
(OK, my "get a better compiler" is a bit harsh here. Interestingly, Intel's C++ compiler leaves in a jl/jne sequence at all optimization levels, as does MSVC.)
I've always used "syntactic sugar" to mean language features that are fundamentally implemented in the front end
But what does that mean? Lots of stuff is implemented in the front end. Without knowing for sure, loops and conditionals are language features that are probably almost always lowered to gotos by the time it hits the back end. Classes are almost guaranteed to be syntactic sugar, even if they have virtual functions. Templates and macros are syntactic sugar.
Sorry, but if you dont know what an immutable object is, then you need to go back to first or second year CS (depending on where you went)
Maybe the person asking the question (I didn't look) was in first or second year CS.
What's even funnier is that the "native type" syntax would also be like immutable objects since you would also need an assignment. its a=a+b not just a+b
a += b.
In fact, even well-aware of how it actually behaves,
Another thing that puzzles me is that Java lambdas seem to be based on the idea of overriding a method of a class. That seems to me to be a critically limiting way of implementing them vs. function prototypes/templates, as there is no way to specify multiple lambdas being passed to the evaluator.
Huh? I'm pretty sure you're not right about it being a limitation, but nor do I understand what you mean from "versus" to the end. Can you elaborate?
If someone can demonstrate that the cellular systems can be reconfigured remotely to send the necessary information on the high speed networks that most of the critical stuff is controlled on, then I'd be worried, but this attack is a long LONG way from being able to do that.
Yep, the attack in the TFA is a long way from being to do that. Of course, this one isn't, and does just what you say.
(Well I don't really know what you mean by the high/medium/low speed networks, but point being that they compromised their car well enough to do anything that can be done by the computer (unlock doors, remote start, disable brakes, activate microphone and listen, activate and receive GPS information, etc.) through the cell network.) The conference talk is on YouTube; you may be interested in 9:30 and ~15:00, though they censor the video for the YouTube version. (Seeing the talk in person actually shows it.)
In any sane car design, the brakes are always stronger than the engine.
It's not a matter of being stronger or weaker, it's a matter of the connection. It'd be reasonable to say that in any sane car design there's a physical connection between the brake pedal and the actual wheels -- but this isn't necessarily the case any more. It's still rare according to Wikipedia, but cars are starting to be produced without it and with systems that have computer-controlled brakes instead. Even without a fully brake-by-wire car, the computer still has significant control over the braking system because of anti-lock brakes.
Compromise the brakes so they don't activate in the first place and it doesn't matter how strong they are.
Just to clarify, because I didn't explain very well. The linked video is to Stephen Checkoway's 30 minute conference talk (and my link specifically goes to the part where he first talks about the cellular exploit). The description of the "theft" bit starts at 15:20 with the censored video at 15:57.
Here's a video if you don't like reading. There's a video of using the telematics vulnerability (e.g. OnStar) to "steal" a car later, though unfortunately it seems that the important bits of that video are censored for the YouTube video. (The same presenter gave a faculty candidate talk here and it was not censored in that version of the presentation.)
We're talking about the ability for a hacker to do something to your car simply by playing a song over your iPod or on a CD. Or a program being injected the next time you get an oil change because the service center's computer had been hacked remotely.
Worse: things like OnStar have cell phones. They can be called and compromised, and can lead to the same dangers as this story demonstrates with the OBD port.
"We systematically synthesize a set of possible external attack vectors as a function of the attackerâ(TM)s ability to deliver malicious input via particular modalities: indirect physical access, short-range wireless access, and long-range wireless access... In each case we find the existence of practically exploitable vulnerabilities that permit arbitrary automotive control without requiring direct physical access." [emphasis in original]
Turns out that car manufactures have been very naughty. And while radios are sort of on a separate bus from actual automotive controls, there are also (compromisable) devices that sit across busses, so there's not a complete air gap.
In that paper, they were able to obtain control over the car's critical automotive systems using techniques ranging from the OBD port (very old news) to CDs with mal-crafted "audio" files put into the stereo to bluetooth connections with the stereo to cellular connections like are used for OnStar.
A stylus-based tablet is actually a decent compromise. You get the benefits (and drawbacks) of being electronic, but still get to scribble on it to your heart's content.
Huh, I'm actually the opposite. I've had a locking mailbox and currently have a "normal" curbside mailbox now. I'd much prefer a door slot to the normal curbside mailbox, and would prefer it to a lesser extent to a locking mailbox. A door slot is more secure than a normal curbside mailbox and I wouldn't have to worry about stopping mail delivery if I'm away for a week or two to prevent the mailbox from filling (or to reduce signs of me being away).
Sure. But that's still very useful in practice, especially in terms of the real threats that people tend to face.
And it still doesn't argue against my main point in this thread, which is that if you have no relationship with your site's (or service's) visitors with which to have already set up your credentials, it is flat out wrong to say that it's safer to use your own CA or self-signed certs than to go via the usual CA system. The latter is much safer.
If you're really worried about government spies, yes, CAs won't help you. But neither will using a self-signed cert.
I'm not claiming that MitMs aren't possible, even on a large scale. What I'm claiming, and I stand by it, is that the number of connections that can be successfully MitM'd is almost certainly far smaller than the number of connections that can be eavesdropped upon.
That'd be an interesting paper actually, comparing the resource requirements. I'm not a networking guy so I don't know though.
And BTW, my interpretations on the italics point and my final "in this world" were formed by i kan reed's original post;
That's actually been my opinion a while. When Firefox tells me "This connection may not be trusted" I'm less inclined to worry, because the CA is just one extra link in the chain to be broken.
It doesn't necessarily have to be out-of-band. If it's a consistent group of users there from the beginning, they would all trust the original certificate once...
...and how are they going to get it in a trustworthy way that first time?
I was responding to you claiming that CA's weren't another link in the chain to be broken. It is.
Maybe my phrasing wasn't the greatest before. I'll try again:
CAs are a link in the security chain. However, if you break that link, what you're left with is exactly what you would have in the first place if you use self-signed certs.
Your final point (the example with Amazon) is somewhat reasonable, but that's considering a different world where no one is using CAs. (If you use a self-signed cert and the NSA replaced it with a CA-signed cert, I suspect the browser would just let that go and not notify you.) Which leads to the point of my replies: if you want to set up a website for arbitrary users to connect to and want to use SSL, CA-signed certs are strictly more secure than self-signed certs.
You are, of course, assuming that those who want the keys can't just hack (or walk their way in) into your server, retrieve your keys and access password. Big assumption.
The same can is equally true if you use self-signed certs or if you run your own CA.
They're a hell of a lot more more trustworthy than "something on the internet I'm connecting to," which is what the alternative is if you want a generally-accessible system.
As long as you have the CA's key, you can sign your own private key to execute a MITM attack. You don't need to have the real private key to do this. In the middle, you decrypt and re-encrypt before sending packets along. The site visitor doesn't know if they're connecting to the "correct" private key. There's no way to know that. They just know they're connecting to a site that's using a public key that has also been used to sign a certificate.
That much I knew, but that's still a much smaller attack surface than what you could do if you had the private key, because you need to be able to carry out a MitM.
From a general perspective, eavesdropping is a lot easier than actually taking an active role. For example, when you're connected to some public wi-fi network it's easy to sniff packets but much more difficult or maybe impossible to carry out a MitM if you're just some third party without network access. (Hopefully, anyway? actually I wouldn't be surprised if that's not true -- seems to ring a bell.) From the perspective of something like the NSA, it means you can't just get a giant pipe of lots of data and go back and decrypt it later if 2 years down the road you say "huh, this guy is suspicious; i wonder what he was doing 2 years ago"; if you want to be able to do that, you have to MitM them now. Slurping down tons of existing traffic for storage and later analysis is something I wouldn't be surprised if the NSA does -- but the capabilities of doing MitM on the same scale are almost certainly not present.
If you have the CA's own key, you can generate a fake certificate that looks real in every way to the browser.
And if you want to attack a site using a self-signed cert, you can generate a fake certificate that looks equally-fake in every way to the browser. Same deal.
The only place where self-signed certificates are more secure is if you have an out-of-band method for transferring your public keys (or transferring a fingerprint or other assurance that public keys sent over an insecure medium are correct) to every place they are needed.
If you run a reasonably small organization, this is feasible. If you want to run, say, a web business, it is not, and CA certificates are more secure.
Slashdot Mirror
A somewhat snarky rebuttal:
Get a better language.
For instance, in Python, functools.total_ordering will give you all six comparison operators when you give it < and ==. In C++, std::rel_ops will do the same thing. (Admittedly, in the C++ version it isn't on a per-class basis without some work because those are function templates, so you either get them for all classes or none.)
But what does that mean? Lots of stuff is implemented in the front end. Without knowing for sure, loops and conditionals are language features that are probably almost always lowered to gotos by the time it hits the back end. Classes are almost guaranteed to be syntactic sugar, even if they have virtual functions. Templates and macros are syntactic sugar.
Maybe the person asking the question (I didn't look) was in first or second year CS.
a += b.
In fact, even well-aware of how it actually behaves,
still seems to me like it should be closer to
than to
.
Huh? I'm pretty sure you're not right about it being a limitation, but nor do I understand what you mean from "versus" to the end. Can you elaborate?
Yep, the attack in the TFA is a long way from being to do that. Of course, this one isn't, and does just what you say.
(Well I don't really know what you mean by the high/medium/low speed networks, but point being that they compromised their car well enough to do anything that can be done by the computer (unlock doors, remote start, disable brakes, activate microphone and listen, activate and receive GPS information, etc.) through the cell network.) The conference talk is on YouTube; you may be interested in 9:30 and ~15:00, though they censor the video for the YouTube version. (Seeing the talk in person actually shows it.)
It's not a matter of being stronger or weaker, it's a matter of the connection. It'd be reasonable to say that in any sane car design there's a physical connection between the brake pedal and the actual wheels -- but this isn't necessarily the case any more. It's still rare according to Wikipedia, but cars are starting to be produced without it and with systems that have computer-controlled brakes instead. Even without a fully brake-by-wire car, the computer still has significant control over the braking system because of anti-lock brakes.
Compromise the brakes so they don't activate in the first place and it doesn't matter how strong they are.
It's not an emergency brake... it's an emergency make-the-car-smell-funny lever.
(Mitch Hedberg, of course. No quote markes because I didn't bother to look up the original wording.)
Just to clarify, because I didn't explain very well. The linked video is to Stephen Checkoway's 30 minute conference talk (and my link specifically goes to the part where he first talks about the cellular exploit). The description of the "theft" bit starts at 15:20 with the censored video at 15:57.
It's a good thing that the black boxes aren't on the same CAN bus that everything else is. Oh wait, they are? Well... shoot.
Good guess: it's been done.
Here's a video if you don't like reading. There's a video of using the telematics vulnerability (e.g. OnStar) to "steal" a car later, though unfortunately it seems that the important bits of that video are censored for the YouTube video. (The same presenter gave a faculty candidate talk here and it was not censored in that version of the presentation.)
Worse: things like OnStar have cell phones. They can be called and compromised, and can lead to the same dangers as this story demonstrates with the OBD port.
So you think. Stock stereo on a recent car? Very possibly untrue.
"We systematically synthesize a set of possible external attack vectors as a function of the attackerâ(TM)s ability to deliver malicious input via particular modalities: indirect physical access, short-range wireless access, and long-range wireless access. .. In each case we find the existence of practically exploitable vulnerabilities that permit arbitrary automotive control without requiring direct physical access." [emphasis in original]
Turns out that car manufactures have been very naughty. And while radios are sort of on a separate bus from actual automotive controls, there are also (compromisable) devices that sit across busses, so there's not a complete air gap.
In that paper, they were able to obtain control over the car's critical automotive systems using techniques ranging from the OBD port (very old news) to CDs with mal-crafted "audio" files put into the stereo to bluetooth connections with the stereo to cellular connections like are used for OnStar.
What? Only the teacher needs one.
Though I did intend to say something about many teachers will feel they're not being paid enough to buy one, though.
A stylus-based tablet is actually a decent compromise. You get the benefits (and drawbacks) of being electronic, but still get to scribble on it to your heart's content.
Huh, I'm actually the opposite. I've had a locking mailbox and currently have a "normal" curbside mailbox now. I'd much prefer a door slot to the normal curbside mailbox, and would prefer it to a lesser extent to a locking mailbox. A door slot is more secure than a normal curbside mailbox and I wouldn't have to worry about stopping mail delivery if I'm away for a week or two to prevent the mailbox from filling (or to reduce signs of me being away).
Sure. But that's still very useful in practice, especially in terms of the real threats that people tend to face.
And it still doesn't argue against my main point in this thread, which is that if you have no relationship with your site's (or service's) visitors with which to have already set up your credentials, it is flat out wrong to say that it's safer to use your own CA or self-signed certs than to go via the usual CA system. The latter is much safer.
If you're really worried about government spies, yes, CAs won't help you. But neither will using a self-signed cert.
I'm not claiming that MitMs aren't possible, even on a large scale. What I'm claiming, and I stand by it, is that the number of connections that can be successfully MitM'd is almost certainly far smaller than the number of connections that can be eavesdropped upon.
That'd be an interesting paper actually, comparing the resource requirements. I'm not a networking guy so I don't know though.
And BTW, my interpretations on the italics point and my final "in this world" were formed by i kan reed's original post;
That opinion is not based in reality.
...and how are they going to get it in a trustworthy way that first time?
Maybe my phrasing wasn't the greatest before. I'll try again:
CAs are a link in the security chain. However, if you break that link, what you're left with is exactly what you would have in the first place if you use self-signed certs.
Your final point (the example with Amazon) is somewhat reasonable, but that's considering a different world where no one is using CAs. (If you use a self-signed cert and the NSA replaced it with a CA-signed cert, I suspect the browser would just let that go and not notify you.) Which leads to the point of my replies: if you want to set up a website for arbitrary users to connect to and want to use SSL, CA-signed certs are strictly more secure than self-signed certs.
The same can is equally true if you use self-signed certs or if you run your own CA.
They're a hell of a lot more more trustworthy than "something on the internet I'm connecting to," which is what the alternative is if you want a generally-accessible system.
That much I knew, but that's still a much smaller attack surface than what you could do if you had the private key, because you need to be able to carry out a MitM.
From a general perspective, eavesdropping is a lot easier than actually taking an active role. For example, when you're connected to some public wi-fi network it's easy to sniff packets but much more difficult or maybe impossible to carry out a MitM if you're just some third party without network access. (Hopefully, anyway? actually I wouldn't be surprised if that's not true -- seems to ring a bell.) From the perspective of something like the NSA, it means you can't just get a giant pipe of lots of data and go back and decrypt it later if 2 years down the road you say "huh, this guy is suspicious; i wonder what he was doing 2 years ago"; if you want to be able to do that, you have to MitM them now. Slurping down tons of existing traffic for storage and later analysis is something I wouldn't be surprised if the NSA does -- but the capabilities of doing MitM on the same scale are almost certainly not present.
And if you want to attack a site using a self-signed cert, you can generate a fake certificate that looks equally-fake in every way to the browser. Same deal.
The only place where self-signed certificates are more secure is if you have an out-of-band method for transferring your public keys (or transferring a fingerprint or other assurance that public keys sent over an insecure medium are correct) to every place they are needed.
If you run a reasonably small organization, this is feasible. If you want to run, say, a web business, it is not, and CA certificates are more secure.
Except that even if the claims in the article are true, no one is getting the RSA private keys.
CAs aren't given your private keys when you register for a certificate. You just give them your public key. Which means that the CA knows absolutely no more about you than anyone who goes to your website does.
Unordained already gave a great rebuttal to your argument, said much better than what I did in my reply a minute ago.