The problem is an attacker does not need to control the domain. They just need to control packets to and from it.
If they control all packets to and from the domain for all users, then they effectively control the domain. If they only control packets to and from the domain for a small subset of users that does not include LetsEncrypt (an assumption of the security model, and why LE likely uses several distributed servers), then they cannot successfully obtain a certificate.
You don't have to MITM LE's infrastructure. All that is needed is to MITM your victim's wire which may well include DNS traffic toward their (authoritative) DNS server.
This is one of the reasons I use a separate DNS provider.
Are you referring to a legitimate domain owners client or an attackers client?
I was referring to MITM attacks on the certification process itself.
For an attacker to initiate the process and successfully complete the validation, they would either need control of the server (or be able to impersonate it), or control of the authoritative DNS records. In either case, the certification is logged publicly by LE. In the former case, you point your DNS somewhere else and generate new certificates. In the latter case, the "attacker" actually does control the hostname*, so the certification is valid.
* The assumption here is that it would be difficult to MITM LE themselves when doing authoritative DNS lookups. Presumably LE uses distributed servers to make this very difficult, but I haven't looked into it.
The concern being if you are launching a man-in-the-middle attack and you are near the server side of the connection, then you could pass such a challenge as well. Sure, in the overwhelmingly more likely case that you are close to the client side, you can't do this sort of thing, but it is possible particularly for small domains for an attacker to be close to the server side.
Not quite -- the client generated a private-public key pair when it first contacted LE, communications between the client and LE are encrypted, and the client answering the challenge is required to sign a nonce provided by LE using their private key. The MITM near the server side of the connection does not have the private key, and so cannot read what the challenge value should be, and cannot sign the nonce.
This isn't about the basics of PKI it's the basics of establishing TRUST that's the heart of my question regarding LE.
The basis of any secure system is TRUST not alphabet soups of cryptographic jargon. It's asking the basic question "WHY SHOULD I TRUST YOU?" and receiving a reasonable, verifiable response.
Trust whom, the site owner? LE? Their CA? If you don't trust root CA, then you are SOL. Better unplug your computer. Otherwise, there's your trust chain: root CA vets LE to a level sufficient to grant them an issuing certificate, LE vets the site owner to a level sufficient to grant them a hostname certificate.
How does LE vet ownership to even assign certificates in the first place?
Ownership of what, the hostname? The client requesting the certificate has to satisfy a challenge, for example placing a file with specific contents at a specific location controlled by the hostname, or populating a specific DNS record with a specific value for that hostname's zone. If the client is able to satisfy those challenges, then it already has complete control over the hostname and the content it serves.
What makes this process secure and trustworthy? If there is no good answer to that question all the cryptography in the world means nothing.
If you aren't willing to engage in a discussion about public keys and cryptographic signatures, there's no way to answer this question for you. The cryptography is how the process is secured, and the public key nature (combined with satisfying the challenge above) is how the CA establishes trust.
How does it demonstrate that? Can you explain specifically what makes this better than self-signed certs? What is the basis of trust used to establish ownership? What prevents an attacker with access to a victims wires from using LE to obtain fraudulent certificates?
Public key cryptography. The client has to satisfy both the domain control challenge, and sign a nonce provided by the CA. The domain control challenge establishes control over the domain. The signed nonce provides client identity verification.
This is why I indent with tabs, and then do alignment/tabulation/etc with spaces. Precise relative-positioning of elements is maintained, but the user can set the tab width to whatever they desire without breaking anything except maximum line width.
It works great, and I even change the tab width periodically myself depending on what exactly I'm doing at any one time, as it lets me change focus from overall program structure to detailed tight blocks without reformatting everything.
Not really. It's a point-to-point link, which means you have two directional antennas pointed at each other. The equipment manufacturer will have a done a link budget over distance, including free space propagation loss, atmospheric losses, and rain fade.
As a Canadian that recently moved the US, the system here is utterly ridiculous and broken. I never know when I should swipe vs insert the chip, I have never been asked for a pin, sometimes I have to sign and sometimes I don't (there doesn't seem to be a clear limit), and there's no tap-to-pay. It's that last part that was killer; I used tap-to-pay for 90% of purchases in Canada, with chip+pin being the remaining 10% of larger purchases like electronics.
There's also an obsession with literal cash, here. People see it as the default, whereas in Canada, cash tended to be a fall-back for most people.
It's truly bizarre. I find it much more annoying to pay for things here.
Depending on the cost of extra CPU cycles vs. the cost of reduced storage, and the relative mix of JPEG files vs. other data files, this could save DropBox quite a bit of money.
Better yet, do it in the client at no CPU cycle cost to Dropbox, and also reducing data transport. Dropbox controls the desktop, mobile, and web clients, so this would be easy to do, and could revert to server-side translation from LEP to JPG for e.g. API clients etc.
Please stop referring to Tesla's autopilot feature as "self-driving". It is not. At best, it is an adaptive cruise control with lane keep assist and some basic collision avoidance capability.
We don't know what the right path to fully autonomous self-driving cars is, but that is almost certainly the long-term solution. I expect the legislative issues to be far more difficult to resolve than the technical ones, and we'll have enough difficulty with it as is; we don't need people muddying the waters by claiming Tesla's autopilot feature is anywhere near an autonomous self-driving vehicle controller.
Don't forget water; it will be the most valuable space resource for the foreseeable future. You can use it as propellant, you can make rocket fuel out of it, it's necessary for most chemical processes you may wish to setup, you need it to live (if you are sending people), you can use it as a radiation shield,... it's a pretty amazing resource.
The problem with parking isn't that there's no parking, it's that there's no parking sufficiently close to where you want to go that you don't mind walking the remaining distance. With self-driving cars that can drop you off then go park themselves, and be summoned when you are ready to leave, this won't be a problem.
Also, a longer term plan is to be able to touch down on land, the sea provides a good environment to practice soft landings because when you fail you are a really long way from any people/infrastructure and because with the motion of the landing ship, once you can reliably do sea landings, surface landings should be relatively easy
That was originally true, but the order kind of ended up getting swapped: SpaceX has already successfully landed a Falcon 9 first stage on land, back at the launch site (different pad, but nearby): https://youtu.be/1B6oiLNyKKI
So we shouldn't be concerned with sidewalks or pedestrian crossings or bicycle paths. Forget about railroad crossing alarms and barriers. Who cares about how many people die because of drunk drivers? Don't worry about whether or not the doctor has washed his hands. More health practitioners die from hepatitis every year than have ever died of AIDS, so why the sudden rush to use rubber gloves all the time? How many other ways of preventing "insignificant" numbers of deaths can you think of? I mean, we all eventually end up dead from some cause or another, right?
I don't hear any presidential candidates demanding unwarranted access to my private, encrypted information to tackle any of those issues.
Why does anyone require 'due diligence' and fact-checking against insane violent assholes like these Sunni extremist fuckstains that laughingly call themselves the 'Islamic State'
Well, for a start, to make sure that's who's actually responsible. (Not saying they're not - or that they don't deserve action anyway, but if it weren't them, then another guilty party could be getting away with no action due to a lack of due diligence)
Slashdot Mirror
Now you have: via Electrek.
Reportedly this is true. See here.
Tesla isn't a car company though; it's an energy company that also sells cars.
The problem is an attacker does not need to control the domain. They just need to control packets to and from it.
If they control all packets to and from the domain for all users, then they effectively control the domain. If they only control packets to and from the domain for a small subset of users that does not include LetsEncrypt (an assumption of the security model, and why LE likely uses several distributed servers), then they cannot successfully obtain a certificate.
Also keep in mind what an LE certificate actual says: https://en.wikipedia.org/wiki/...
If the attacker controls the domain, then the certificate is valid.
You don't have to MITM LE's infrastructure. All that is needed is to MITM your victim's wire which may well include DNS traffic toward their (authoritative) DNS server.
This is one of the reasons I use a separate DNS provider.
Are you referring to a legitimate domain owners client or an attackers client?
I was referring to MITM attacks on the certification process itself.
For an attacker to initiate the process and successfully complete the validation, they would either need control of the server (or be able to impersonate it), or control of the authoritative DNS records. In either case, the certification is logged publicly by LE. In the former case, you point your DNS somewhere else and generate new certificates. In the latter case, the "attacker" actually does control the hostname*, so the certification is valid.
* The assumption here is that it would be difficult to MITM LE themselves when doing authoritative DNS lookups. Presumably LE uses distributed servers to make this very difficult, but I haven't looked into it.
The concern being if you are launching a man-in-the-middle attack and you are near the server side of the connection, then you could pass such a challenge as well. Sure, in the overwhelmingly more likely case that you are close to the client side, you can't do this sort of thing, but it is possible particularly for small domains for an attacker to be close to the server side.
Not quite -- the client generated a private-public key pair when it first contacted LE, communications between the client and LE are encrypted, and the client answering the challenge is required to sign a nonce provided by LE using their private key. The MITM near the server side of the connection does not have the private key, and so cannot read what the challenge value should be, and cannot sign the nonce.
This isn't about the basics of PKI it's the basics of establishing TRUST that's the heart of my question regarding LE.
The basis of any secure system is TRUST not alphabet soups of cryptographic jargon. It's asking the basic question "WHY SHOULD I TRUST YOU?" and receiving a reasonable, verifiable response.
Trust whom, the site owner? LE? Their CA? If you don't trust root CA, then you are SOL. Better unplug your computer. Otherwise, there's your trust chain: root CA vets LE to a level sufficient to grant them an issuing certificate, LE vets the site owner to a level sufficient to grant them a hostname certificate.
How does LE vet ownership to even assign certificates in the first place?
Ownership of what, the hostname? The client requesting the certificate has to satisfy a challenge, for example placing a file with specific contents at a specific location controlled by the hostname, or populating a specific DNS record with a specific value for that hostname's zone. If the client is able to satisfy those challenges, then it already has complete control over the hostname and the content it serves.
What makes this process secure and trustworthy? If there is no good answer to that question all the cryptography in the world means nothing.
If you aren't willing to engage in a discussion about public keys and cryptographic signatures, there's no way to answer this question for you. The cryptography is how the process is secured, and the public key nature (combined with satisfying the challenge above) is how the CA establishes trust.
How does it demonstrate that? Can you explain specifically what makes this better than self-signed certs? What is the basis of trust used to establish ownership? What prevents an attacker with access to a victims wires from using LE to obtain fraudulent certificates?
Public key cryptography. The client has to satisfy both the domain control challenge, and sign a nonce provided by the CA. The domain control challenge establishes control over the domain. The signed nonce provides client identity verification.
https://letsencrypt.org/how-it-works/
This is why I indent with tabs, and then do alignment/tabulation/etc with spaces. Precise relative-positioning of elements is maintained, but the user can set the tab width to whatever they desire without breaking anything except maximum line width.
It works great, and I even change the tab width periodically myself depending on what exactly I'm doing at any one time, as it lets me change focus from overall program structure to detailed tight blocks without reformatting everything.
That isn't what autopilot in an airplane means at all. Stop spreading misinformation.
Not really. It's a point-to-point link, which means you have two directional antennas pointed at each other. The equipment manufacturer will have a done a link budget over distance, including free space propagation loss, atmospheric losses, and rain fade.
As a Canadian that recently moved the US, the system here is utterly ridiculous and broken. I never know when I should swipe vs insert the chip, I have never been asked for a pin, sometimes I have to sign and sometimes I don't (there doesn't seem to be a clear limit), and there's no tap-to-pay. It's that last part that was killer; I used tap-to-pay for 90% of purchases in Canada, with chip+pin being the remaining 10% of larger purchases like electronics.
There's also an obsession with literal cash, here. People see it as the default, whereas in Canada, cash tended to be a fall-back for most people.
It's truly bizarre. I find it much more annoying to pay for things here.
Depending on the cost of extra CPU cycles vs. the cost of reduced storage, and the relative mix of JPEG files vs. other data files, this could save DropBox quite a bit of money.
Better yet, do it in the client at no CPU cycle cost to Dropbox, and also reducing data transport. Dropbox controls the desktop, mobile, and web clients, so this would be easy to do, and could revert to server-side translation from LEP to JPG for e.g. API clients etc.
Please stop referring to Tesla's autopilot feature as "self-driving". It is not. At best, it is an adaptive cruise control with lane keep assist and some basic collision avoidance capability.
We don't know what the right path to fully autonomous self-driving cars is, but that is almost certainly the long-term solution. I expect the legislative issues to be far more difficult to resolve than the technical ones, and we'll have enough difficulty with it as is; we don't need people muddying the waters by claiming Tesla's autopilot feature is anywhere near an autonomous self-driving vehicle controller.
Don't forget water; it will be the most valuable space resource for the foreseeable future. You can use it as propellant, you can make rocket fuel out of it, it's necessary for most chemical processes you may wish to setup, you need it to live (if you are sending people), you can use it as a radiation shield, ... it's a pretty amazing resource.
To be fair, the first one they successfully landed was always destined to end up as a lawn ornament.
The problem with parking isn't that there's no parking, it's that there's no parking sufficiently close to where you want to go that you don't mind walking the remaining distance. With self-driving cars that can drop you off then go park themselves, and be summoned when you are ready to leave, this won't be a problem.
Ugh, no coffee this morning. complete stop.
Well, except the part where the rocket did come to a https://www.instagram.com/p/BAqirNbwEc0/.
Also, a longer term plan is to be able to touch down on land, the sea provides a good environment to practice soft landings because when you fail you are a really long way from any people/infrastructure and because with the motion of the landing ship, once you can reliably do sea landings, surface landings should be relatively easy
That was originally true, but the order kind of ended up getting swapped: SpaceX has already successfully landed a Falcon 9 first stage on land, back at the launch site (different pad, but nearby): https://youtu.be/1B6oiLNyKKI
So we shouldn't be concerned with sidewalks or pedestrian crossings or bicycle paths. Forget about railroad crossing alarms and barriers. Who cares about how many people die because of drunk drivers? Don't worry about whether or not the doctor has washed his hands. More health practitioners die from hepatitis every year than have ever died of AIDS, so why the sudden rush to use rubber gloves all the time? How many other ways of preventing "insignificant" numbers of deaths can you think of? I mean, we all eventually end up dead from some cause or another, right?
I don't hear any presidential candidates demanding unwarranted access to my private, encrypted information to tackle any of those issues.
Why does anyone require 'due diligence' and fact-checking against insane violent assholes like these Sunni extremist fuckstains that laughingly call themselves the 'Islamic State'
Well, for a start, to make sure that's who's actually responsible. (Not saying they're not - or that they don't deserve action anyway, but if it weren't them, then another guilty party could be getting away with no action due to a lack of due diligence)
Here is a perfect example: Toronto Games Critic [Veerender Jubbal] Falsely Linked with Paris Attacks .
Device removal on ZFS may be a thing, and may not require block pointer rewrite; it's the latter that is probably not going to happen.