For the most common cases this could be provided as a service (like DDNS) by the device manufacturer.
In the case of server software installed on a Raspberry Pi single-board computer, who is "the device manufacturer"? Raspberry Pi Foundation? Sony? The publisher of the server software?
It's in case you saved permission for somesite.com to perform these sensitive operations, so that a malicious actor can't exploit these saved permissions by hijacking somesite.com.
No, but I expect a ballpark estimate of the cost of this service.
And how does anybody sell advertising on a website? You contact advertisers. You show them how your content will reach their customers.
I am indeed asking for a guide to help people who are switching away from YouTube learn how to efficiently "contact advertisers" and "show them how your content will reach their customers."
Unless Let's Encrypt has changed their policy since I started using them, a certificate has to have an FDQN that's routable on the open internet, and they verify the host(s) are listening on port 443 at least once during the creation or renewal process.
That is true of the http-01 challenge (though the port is 80). But instead of the http-01 challenge, you can use the dns-01 challenge, which requires a FQDN that's routable on the open Internet and listening on port 53. The machine involved need not be on your private network.
Let's Encrypt won't issue or renew certs for anybody's internal networks
Yes it will. Here's the overall procedure to obtain a certificate from Let's Encrypt or another ACME CA using the dns-01 challenge:
1. Buy a domain, preferably from a registrar whose bundled zone hosting has an API supported by an ACME client's. 2. Set up zone hosting for that domain on the public Internet. 3. Using your ACME client, begin a dns-01 challenge with the CA. 4. Post the response to this challenge as TXT records in your domain. Your ACME client may be able to perform this step automatically if your zone host's API is supported. 5. Using your ACME client, notify the CA that the response is ready, and retrieve your certificates.
In step 5, Let's Encrypt will contact your zone host through several routes on the open Internet. Nobody will attempt to connect to your internal network.
Using a DNS entry as a root of trust will work once DNSSEC support becomes a standard feature in the zone hosting that major domain name registrars bundle with registration. Until that comes to pass, anyone with power to spoof DNS can also spoof your certificate.
DV certificates identify the machine on the other end for the purposes of creating an encrypted channel. So explain why its so bad?
Consider this: bankofarnerica.com has an "RN" in it, but it's hard for especially non-technical users to see. Homoglyphs like this can be and have been used in phishing attacks. Under domain validation, what prevents widespread typosquatting the way organization validation can?
how does that help the enterprise which has users using Android devices?
I don't see how your response helps sites that use an internal CA, which is a perfectly legitimate activity.
If they're websites, they'd be viewed using either Chrome, whose network security config allows use of user-installed certificates, or Firefox, which has its own TLS engine that also allows use of user-installed certificates. If they're not "sites" but native apps distributed as free software that access an internal HTTPS server's REST API, then the business can download each application's source code from the repository linked on F-Droid and rebuild the APK with a network security config referring to a pinned copy of the internal certificate.
And [a personal portfolio site] doesn't need to be encrypted
Let's say a web developer's portfolio site contains demonstrations of web applications, and the users of these web application can create accounts. Without encryption, how should the web developer protect the passwords and session tokens of the users of the web application from interception when exhibiting this application to the public?
Let's say a web developer's portfolio site contains demonstrations of web applications, one of which uses Service Workers or another web API that has been restricted to secure contexts. Without encryption, how should the web developer exhibit this application to the public?
So let's say someone does go the IndieWeb route to replace YouTube. What means would you recommend for a small-time video producer to sell preroll ad time and promote the videos to people who have watched videos with similar subject matter?
Let me try to rephrase how I understood DarkOx's comment:
Issuing TLS certificates based on domain validation, not organization validation, is literally the worst thing to happen to security on the internet. It's theater and it's dangerous.
CAA records are useless when I hijack the DNS in the first place.
I'm interested to see how you plan to hijack the DNS in a way that evades the following three defenses:
Breadth of hijacking
At what point would you hijack the DNS? A domain-validating certificate authority queries DNS through several Internet routes. How had you planned to hijack them all, especially if the domain's authoritative DNS servers are on different/16s?
Expiry
Certificates issued by Let's Encrypt expire after 90 days, and organizations may renew them at 60, 73, 85, or whatever day intervals. How long do you plan to keep up the DNS hijacking?
Certificate Transparency
If a CA issues an certificate to a hijacker, the domain's rightful owner can check CT logs and find your certificate. The policy change described in the featured article encourages CAs to keep their CT logs complete.
We should allow free self signed certificates with no warnings. I should not have to link myself up to some 3rd party of any kind to operate my website.
Under your proposal, what distinguishes the self-signed certificate that you generated for your domain from the self-signed certificate that the operator of an intercepting proxy (a "man in the middle") generated for your domain, particularly on a client's first visit?
Just to get a ballpark figure to guide further discussion of your opinion on Let's Encrypt: How much do you think someone ought to have to pay per year in order to host a personal portfolio site?
Does Let's Encrypt verify identity, I can't find anything on their site about it.
Let's Encrypt is a domain-validating certificate authority, which issues domain-validated certificates. Every such CA verifies that the person requesting a certificate is the same person who controls the domain's DNS. What other sort of "identity" did you have in mind?
If a CA is not verifying identity then what use is their certificate?
If a domain registrar is not verifying identity then what use is their domain?
Which is exactly why let's encrypt should have their trust revoked. Such lax policies mean even illegitimate sites can get certificates, just look up all the paypal scammers using let's encrypt to show up as trusted.
By the same reasoning: Which is exactly why domain name registrars should have their trust revoked. Such lax policies mean even illegitimate sites can get certificates, just look up all the paypal scammers using domain names to show up as trusted.
IMO all certificates should be EV in the current internet if we want security.
I thought EV certificates were available only to corporations or LLCs, not to individuals. If someone puts up a site to show her personal portfolio, would you prefer to require her to incorporate first?
But the current situation - Let's decrypt being able to issue a DV for any EV issued domain, is completely wrong.
That's what certificate authority authorization (CAA) records are for. If a domain owner publishes a CAA record that doesn't include Let's Encrypt, Let's Encrypt will not issue a certificate for that domain.
A lot of people, including myself use LetsEncrypt on a CPanel based hosting account to generate certs for a website.
Are those local, self-signed certificates or something that is registered somewhere?
You could answer that question with five seconds on a search engine. Google Search for let's encrypt certificate transparency produces, as its first result, a document stating the following: "We submit all certificates to Certificate Transparency logs as we issue them."
All websites with a fully qualified domain name qualify for a domain-validated certificate without charge from Let's Encrypt. Every certificate that Let's Encrypt issues is logged in CT.
If they did care about the end user's security, they wouldn't make stupid changes like not trusting end-user / admin installed CA certs by default.
Chrome opts in through its network security config file, and Firefox has its own TLS engine. So this affects mostly native apps that use Android's TLS engine.
Since when does removing / forbidding the user's input on trust somehow boost their security?!?!?
Malware has in the past added certificates as a means of intercepting apps' traffic. So have governments.
No, we need warnings for certificates that aren't trusted. Otherwise SSL does nothing to prevent man-in-the-middle attacks.
But without a fully qualified domain name, CAs shall not issue a trusted certificate. So we also need a reliable way to provide trustable names for devices on a non-technical users' home network that have a web-based administration interface, such as a modem, router, printer, or NAS.
What would be ideal is to support secure DNS with certificates in the DNS.
I agree that DANE would be ideal. But DANE relies on DNSSEC, which has faced practical problems that hinder adoption. Before about a year and a half ago, DNSSEC's root zone key was too short (1024 bit RSA) for browsers to accept as part of a certificate chain. And many domain name registrars bundle zone hosting with a domain, but a lot of these (such as GoDaddy) have charged more for zone hosting with DNSSEC than for zone hosting without DNSSEC.
Given name and surname correlate significantly with race.
Not in the US, where most blacks still use the Anglo-Saxon surnames their ancestors acquired from their owners when they were slaves.
Given names of African-Americans still correlate with race, and surnames correlate with ancestry in situations that do not involve slavery (which I imagine to be the majority).
Slashdot Mirror
For the most common cases this could be provided as a service (like DDNS) by the device manufacturer.
In the case of server software installed on a Raspberry Pi single-board computer, who is "the device manufacturer"? Raspberry Pi Foundation? Sony? The publisher of the server software?
How much do you plan to charge for this guide, both per copy and and as a license to syndicate it?
It's in case you saved permission for somesite.com to perform these sensitive operations, so that a malicious actor can't exploit these saved permissions by hijacking somesite.com.
Do you expect to get this service for free?
No, but I expect a ballpark estimate of the cost of this service.
And how does anybody sell advertising on a website? You contact advertisers. You show them how your content will reach their customers.
I am indeed asking for a guide to help people who are switching away from YouTube learn how to efficiently "contact advertisers" and "show them how your content will reach their customers."
Unless Let's Encrypt has changed their policy since I started using them, a certificate has to have an FDQN that's routable on the open internet, and they verify the host(s) are listening on port 443 at least once during the creation or renewal process.
That is true of the http-01 challenge (though the port is 80). But instead of the http-01 challenge, you can use the dns-01 challenge, which requires a FQDN that's routable on the open Internet and listening on port 53. The machine involved need not be on your private network.
Let's Encrypt won't issue or renew certs for anybody's internal networks
Yes it will. Here's the overall procedure to obtain a certificate from Let's Encrypt or another ACME CA using the dns-01 challenge:
1. Buy a domain, preferably from a registrar whose bundled zone hosting has an API supported by an ACME client's.
2. Set up zone hosting for that domain on the public Internet.
3. Using your ACME client, begin a dns-01 challenge with the CA.
4. Post the response to this challenge as TXT records in your domain. Your ACME client may be able to perform this step automatically if your zone host's API is supported.
5. Using your ACME client, notify the CA that the response is ready, and retrieve your certificates.
In step 5, Let's Encrypt will contact your zone host through several routes on the open Internet. Nobody will attempt to connect to your internal network.
Using a DNS entry as a root of trust will work once DNSSEC support becomes a standard feature in the zone hosting that major domain name registrars bundle with registration. Until that comes to pass, anyone with power to spoof DNS can also spoof your certificate.
DV certificates identify the machine on the other end for the purposes of creating an encrypted channel. So explain why its so bad?
Consider this: bankofarnerica.com has an "RN" in it, but it's hard for especially non-technical users to see. Homoglyphs like this can be and have been used in phishing attacks. Under domain validation, what prevents widespread typosquatting the way organization validation can?
how does that help the enterprise which has users using Android devices?
I don't see how your response helps sites that use an internal CA, which is a perfectly legitimate activity.
If they're websites, they'd be viewed using either Chrome, whose network security config allows use of user-installed certificates, or Firefox, which has its own TLS engine that also allows use of user-installed certificates. If they're not "sites" but native apps distributed as free software that access an internal HTTPS server's REST API, then the business can download each application's source code from the repository linked on F-Droid and rebuild the APK with a network security config referring to a pinned copy of the internal certificate.
And [a personal portfolio site] doesn't need to be encrypted
Let's say a web developer's portfolio site contains demonstrations of web applications, and the users of these web application can create accounts. Without encryption, how should the web developer protect the passwords and session tokens of the users of the web application from interception when exhibiting this application to the public?
Let's say a web developer's portfolio site contains demonstrations of web applications, one of which uses Service Workers or another web API that has been restricted to secure contexts. Without encryption, how should the web developer exhibit this application to the public?
So let's say someone does go the IndieWeb route to replace YouTube. What means would you recommend for a small-time video producer to sell preroll ad time and promote the videos to people who have watched videos with similar subject matter?
Let me try to rephrase how I understood DarkOx's comment:
Issuing TLS certificates based on domain validation, not organization validation, is literally the worst thing to happen to security on the internet. It's theater and it's dangerous.
CAA records are useless when I hijack the DNS in the first place.
I'm interested to see how you plan to hijack the DNS in a way that evades the following three defenses:
Breadth of hijacking At what point would you hijack the DNS? A domain-validating certificate authority queries DNS through several Internet routes. How had you planned to hijack them all, especially if the domain's authoritative DNS servers are on differentWe should allow free self signed certificates with no warnings. I should not have to link myself up to some 3rd party of any kind to operate my website.
Under your proposal, what distinguishes the self-signed certificate that you generated for your domain from the self-signed certificate that the operator of an intercepting proxy (a "man in the middle") generated for your domain, particularly on a client's first visit?
What doesn't make sense is [appliances on LANs] using https with default certificates just to tick of the "it's secure" checkbox.
That's partly a reaction to browser implementation of Secure Contexts, a W3C spec that reserves certain web APIs for HTTPS sites.
Let's Encrypt certificates are issued under an intermediate that has always been cross-signed by IdenTrust, an older and more established CA.
Just to get a ballpark figure to guide further discussion of your opinion on Let's Encrypt: How much do you think someone ought to have to pay per year in order to host a personal portfolio site?
Why do home devices need to have trusted SSL certs?
Because Service Workers and several other web platform APIs are restricted to secure contexts per W3C's spec. For example, a browser may restrict the Fullscreen API or Presentation API to secure contexts as a mitigation against phishing by replicating the chrome of the operating system and web browser. In such a browser, the web interface of a NAS on which video is stored will not be able to present the video in the full screen.
Does Let's Encrypt verify identity, I can't find anything on their site about it.
Let's Encrypt is a domain-validating certificate authority, which issues domain-validated certificates. Every such CA verifies that the person requesting a certificate is the same person who controls the domain's DNS. What other sort of "identity" did you have in mind?
If a CA is not verifying identity then what use is their certificate?
If a domain registrar is not verifying identity then what use is their domain?
Anonymous Coward wrote:
Which is exactly why let's encrypt should have their trust revoked. Such lax policies mean even illegitimate sites can get certificates, just look up all the paypal scammers using let's encrypt to show up as trusted.
By the same reasoning:
Which is exactly why domain name registrars should have their trust revoked. Such lax policies mean even illegitimate sites can get certificates, just look up all the paypal scammers using domain names to show up as trusted.
IMO all certificates should be EV in the current internet if we want security.
I thought EV certificates were available only to corporations or LLCs, not to individuals. If someone puts up a site to show her personal portfolio, would you prefer to require her to incorporate first?
But the current situation - Let's decrypt being able to issue a DV for any EV issued domain, is completely wrong.
That's what certificate authority authorization (CAA) records are for. If a domain owner publishes a CAA record that doesn't include Let's Encrypt, Let's Encrypt will not issue a certificate for that domain.
A lot of people, including myself use LetsEncrypt on a CPanel based hosting account to generate certs for a website.
Are those local, self-signed certificates or something that is registered somewhere?
You could answer that question with five seconds on a search engine. Google Search for let's encrypt certificate transparency produces, as its first result, a document stating the following: "We submit all certificates to Certificate Transparency logs as we issue them."
All websites with a fully qualified domain name qualify for a domain-validated certificate without charge from Let's Encrypt. Every certificate that Let's Encrypt issues is logged in CT.
If they did care about the end user's security, they wouldn't make stupid changes like not trusting end-user / admin installed CA certs by default.
Chrome opts in through its network security config file, and Firefox has its own TLS engine. So this affects mostly native apps that use Android's TLS engine.
Since when does removing / forbidding the user's input on trust somehow boost their security?!?!?
Malware has in the past added certificates as a means of intercepting apps' traffic. So have governments.
No, we need warnings for certificates that aren't trusted. Otherwise SSL does nothing to prevent man-in-the-middle attacks.
But without a fully qualified domain name, CAs shall not issue a trusted certificate. So we also need a reliable way to provide trustable names for devices on a non-technical users' home network that have a web-based administration interface, such as a modem, router, printer, or NAS.
What would be ideal is to support secure DNS with certificates in the DNS.
I agree that DANE would be ideal. But DANE relies on DNSSEC, which has faced practical problems that hinder adoption. Before about a year and a half ago, DNSSEC's root zone key was too short (1024 bit RSA) for browsers to accept as part of a certificate chain. And many domain name registrars bundle zone hosting with a domain, but a lot of these (such as GoDaddy) have charged more for zone hosting with DNSSEC than for zone hosting without DNSSEC.
Given name and surname correlate significantly with race.
Not in the US, where most blacks still use the Anglo-Saxon surnames their ancestors acquired from their owners when they were slaves.
Given names of African-Americans still correlate with race, and surnames correlate with ancestry in situations that do not involve slavery (which I imagine to be the majority).