Slashdot Mirror

Considering how many are downloading from wifi or untrusted router, it doesn't make sense to use http because you can get you file change during the download. HTTPS wont slow you down and will offer basic security against the hacker next door. For web hosting, https://letsencrypt.org/ offer free SSL certificates.

I don't see why a self signed certificate gets a warning, but http doesn't it is no less secure.

A self-signed certificate gives a false sense of security, whereas the http: scheme gives a true sense of insecurity. A true sense is better than a false sense.

It is really annoying that you have to pay someone a recurring fee just to add a little security.

Every domain name registrant is entitled to a reasonable number of certificates from Let's Encrypt without charge. Or by "someone" do you refer to Gandi, Namecheap, Amazon Route 53, and other domain name registrars?

The fact that the Internet's design allows this behavior has been known for decades. The only thing that is new is China was caught doing it, though probably most world governments have done it by now. That is why many in the industry are pushing for 100% HTTPS adoption. It's free and easy now thanks to https://letsencrypt.org/

It's more correct to say that the Let's Encrypt root certificate is now a trusted root certificate in the certificate store of all major browsers.

Yeah, I'm guessing whoever wrote the summary mis-paraphrased the press release on Let's Encrypt's website, which says that it is now "trusted by all major root programs" (i.e., those by Mozilla, Microsoft, Apple, etc., where it is decided which root certificates are distributed with their products). It could almost be a slip of the "tongue" since "root certificate" is a much more common phrase, but then they kept saying it...

Very vague statement, what is "old" and "older"? Even IE6 (xp sp3) qualifies! https://letsencrypt.org/docs/c...

It is *comaptible* with all of these via IdenTrust. Does not mean, all of these will trust directly Let's Encrypt....

Letâ(TM)s Encrypt is a free, automated, and open certificate authority brought to you by the non-profit Internet Security Research Group (ISRG).

So if you need an SSL certificate for cheap, you can go to them. https://letsencrypt.org/

Very vague statement, what is "old" and "older"? Even IE6 (xp sp3) qualifies! https://letsencrypt.org/docs/c...

The relatively short length is intentional

This is a boneheaded rationale. It means that the risk of the process (automated or not) breaking arises more often than it needs to.

Many users want encryption that is in place and remains in place, not encryption that stops working, or potentially stops working, at very short intervals. Let's Encrypt produces a series of short-interval risks of failure. Not going to bite on that.

The relatively short length is intentional: https://letsencrypt.org/2015/1...
It's long enough so that you *can* manually update but short enough that it's a hassle to encourage people to automate.

google approved certificates complete with extortionate prices

Let's Encrypt offers TLS certificates to domain owners without charge. Its website lists the division of Google that maintains Chrome as a sponsor. So no, I don't see Chrome requiring "extortionate prices" for TLS certificates any time soon.

https://letsencrypt.org/

)$0.00

Let's encrypt is only good for public websites with public DNS entries. If it's an internal LAN or not on the Internet for some reason then you're out of luck, and there are no other good tools that make it simple.

No one needs to afford a certificate just use a Let's Encrypt at https://letsencrypt.org/

He already said there's a technical barrier against the blogger masses here. It's not a money problem, but an awareness one. Heck, no bloggers these days maintain their own sites from the ground up. They have already lost the war, because blogger and Facebook and Twitter own their content, and can lock them out of it. When they squeeze the noose and forcibly close / cancel the blogger's account for being politically opposite, the blogger has little they can do if they're not aware of hosting options. And bloggers aint going to take a crash course in rolling their own.

But for the few that try to... they may find that those old tutorials don't quite cover let's encrypt and the like... think of the same knowledge gaps that have plague most new smalltime PHP frontend developers --there are tons of search results showing tutorials that are taken a gold standards. As has been discussed here, tutorials have a dirty secret that we gloss over. They don't tend to warn about armoring the code against SQL injections, for example. They don't spend time with failing safe, because proofs of concept will NEVER end up on production... nudge! nudge!
Thus, the battered, unwashed masses of refugees who are far from IT experts never get proper instruction till it's too late as the server is on fire. Eventually experience will teach us all, but it would be nice if there were licenses for this kind of stuff, the way medics and architects and lawyers, etc. are prepated to meet some safety baselines and command some modicum of trust from us laymen.

It seems like it would be easier all around if let's encrypt used longer expiration dates.

Let's Encrypt disagrees. They actually plan on making it shorter once people get used to automation: https://letsencrypt.org/2015/1...

It will certainly help Google sell certificates ...

How will it do that when the Internet Security Research Group (which is backed by the EFF among others--including, yes, Google) is giving them away for free?

The problem here is the assumption (which Winer got from God-only-knows where) that Google is the one behind the drive to use https, when, in fact, the EFF and Tor are major backers of the push. And, while I don't trust Google as far as I could throw them, I trust the EFF and Tor a lot more than I trust this Winer guy.

Dave Winer seems to think this is a Google thing. In point of fact, HTTPS Everywhere is sponsored by the EFF and Tor. And Let's Encrypt is run by an umbrella organization whose members include the EFF and Mozilla as well as Google, Cisco, and Akamai.

I don't have much trust for Google, but I do have a lot more trust for the EFF than I do for some random software developer. Even if he's old. I'm sure Winer is well-intentioned (given his history), but he doesn't seem to have done his research very well, in this case.

The EFF's reasons for supporting https are a lot stronger than Winer seems to realize. Google's reasons, I can't address, since I'm not familiar with them, but the EFF's arguments are pretty strong. MITM attacks at the government actor level are not just hypothetical.

From the EFF's page:

Content injection is when someone adds data or code to your communications with an HTTP web page. For example, it's how GCHQ and NSA took over a Belgian ISP's computers. Content injection is also how China took down GitHub with a massive DDoS attack, dubbed "The Great Cannon". Content injection is also becoming popular with ISPs. Verizon injected tracking headers into every request made by their customers. And Comcast injects pop-ups into sites where they don't belong. All of these attacks can be stopped by HTTPS, provided it is implemented and made default on enough sites.

Now, I admit there are still some questions which aren't as frequently discussed as they should be, such as private LANs where https isn't an option. (I have http services running on such a LAN myself.) But that can be dealt with. For IP4, it's fairly easy--whitelist private ranges. For IP6, you'd have to have a way of designating your trusted network. But it can be dealt with. And the public Internet should be encrypted. Anyone who argues otherwise is simply clueless. (Or culpable.)

https://letsencrypt.org/
Simple to set up. Renews itself.

Zero dollars will get you a fully qualified domain from a DynDNS type of service.

If on your first attempt you hit the weekly rate limit for subdomains under a particular dynamic DNS provider, how practical is it to retry at random intervals for upwards of two days, as another Anonymous Coward suggested?

1. Why do you want your printer to show up in Google search results?

The summary mentions not only Search but also Chrome.

2. Do you really want your printer accessible directly over the Internet?

No, but web browsers' enforcement of Secure Contexts policy currently makes no distinction between machines on the LAN and machines on the Internet.

I use Let's Encrypt on a NoIP domain (DynDNS) without problems

How did you manage to get the request for your subdomain past the rate limit of 20 certificates per registrable domain per week? Has No-IP completed the Public Suffix List add process for all its domains?

It's 2018, give me a GUI front end that has one button: Obtain and apply Cert. I click it, select the desired provider

I don't see how that can be made to work automatically given that many dynamic DNS providers require passing a CAPTCHA before obtaining or renewing a subdomain.

https://letsencrypt.org/

)$0.00

If people can't find what they want with Google they can use a different search engine such as https://duckduckgo.com/

No one needs to afford a certificate just use a Let's Encrypt at https://letsencrypt.org/

Is the EFF trying to sell certificates now?

Not quite, but Electronic Frontier Foundation is sponsoring the Let's Encrypt CA. In addition, many of the same companies sponsor both EFF (source) and LE (source). Fastly and DigitalOcean, for example, sponsor both organizations.

once negotiated it prevent interception of the message being TRANSPORTED over the network. In order to do this self-signed certificates are perfectly adequate.

"Negotiation" of a TLS connection includes the client accepting the certificate that the server presents. This is fine over a LAN, as (say) a printer can write the fingerprint of its self-signed certificate to paper in text and QR code form, or a home server appliance can use a composite, VGA, or HDMI output or a built-in status LCD to display the fingerprint. But it's less fine at Internet scale unless there's some convenient means of out-of-band communication between the operators of the client and the server. How would it be practical for every MTA operator to verify every other MTA's self-signed certificate through out-of-band communication?

Just like every homeowner is expected to buy connectivity and addressing from their isp?

And when smartphones were new, a lot of people were reluctant to buy a cellular data plan because they were already buying connectivity from their home ISP. Some householders just don't want yet another perpetual utility bill, which means yet another company dipping into the family's checking account and potentially exposing said account to accidental or fraudulent withdrawals that cause overdrafts.

if you're content to use the same domain as thousands of others then there are many free options

You mean free dynamic DNS? One drawback of this has been that Let's Encrypt issues only 20 certificates per registrable domain per week. The dynamic DNS provider has to apply to Mozilla for inclusion on the Public Suffix List, which is administered on a Microsoft-run website. Some are unwilling, and last I checked, others' applications were in a months-long backlog.

and nothing to stop the isp from allocating a subdomain to their customers.

Of course there is: The major last mile ISPs have a business policy not to let home users run servers in the first place. I concede that ISPs have power to amend this policy, but you'd have to show ISPs a good case for amending this policy, as upgrades to more expensive business-class service make them money.

Plus there is always .local and llmnr/mdns if you don't need global reachability of your hostnames.

Neither Let's Encrypt nor any other trusted-by-default HTTPS certificate authority does .local. It violates the CAB Forum's Baseline Requirements.

LetsEncrypt submits all certificates as they issue them: https://letsencrypt.org/certif... More details in cert transparency: https://www.certificate-transp...

In answer to your subject, from https://letsencrypt.org/certif...:

We are dedicated to transparency in our operations and in the certificates we issue. We submit all certificates to Certificate Transparency logs as we issue them. You can view all issued Let’s Encrypt certificates via these links:...

So LetsEncrypt certs will work fine with Chrome.

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."

You can use several DDNS providers with letsencrypt

And there are several that you can't use because the provider hasn't completed the process to add itself to the Public Suffix List. If a DDNS provider is not on the PSL, whether by the provider's ignorance of the PSL, by the provider's choice to remain off the PSL, or by the PSL's own backlog, then all users of that provider put together are limited to 20 certificates per week, and other users are likely to have already obtained those certificates before you.

Here's directions for the one I use, duckdns.

I see that Duck DNS is on the PSL. Do you project that Duck DNS will remain in operation for the foreseeable future?

Another problem is DDNS providers that go behind a paywall. Dyn started charging for all services once it became popular, making it no better than registering a domain.

But I wish they would find a way to make encryption secure and much more cheaper (Certificates are still a killer, in terms of ease of installing, and price you often need to pay for them, for the amount of actual validation they give you for it)

Try looking at Let's Encrypt if you want free certificates.

Let me help you with your problem. https://letsencrypt.org/

And yet we continue to write checks to CAs for certificates that we can't trust.

Not if we use letsencrypt. You said it yourself that we cannot trust someone simply because they have a certificate. He could be the guy selling you fake Rolex from the back of his van, but at least you know that he owns and controls the domain (i.e. the van). That's really all that you can guarantee with certificates from an identity perspective anyway, that a public facing identity matches a domain controlled by the one presenting it to you. Whether that means that you should trust any further dealings with that domain is up to you at that point.

This is silly. Google is saying every website needs to be https. That's not true and is a waste of money and time to make every site https

I completely disagree. Companies that run websites should already be serving their websites via https. This will probably push companies who aren't using encryption to start or face backlash from users. It is very easy to make use of https! Any competent website administrator should already know how to do this. It isn't even an issue of money either. Let's Encrypt offers free certificates so I don't want to hear that it is a time and money issue.

You can get a FQDN for free under other existing domains.

But then you're more likely to run into CA-imposed rate limits because many subdomain providers aren't on the Public Suffix List yet.

The web browser caches resources delivered through HTTPS the same way as resources delivered through cleartext HTTP. The only thing you lose is being able to cache on an intermediate proxy, but that is relevant if you're splitting one dial-up connection among multiple clients.

Then there is the issue of small timers who want to serve a web page from home, using an old computer and dynamic hostname.

File a support ticket with your dynamic DNS provider to request addition to the Public Suffix List. If a dynamic DNS provider is on the Public Suffix List, Let's Encrypt issues 20 certificates per customer per week instead of 20 per provider per week. The other benefit of being on the PSL is that sites on the same dynamic DNS provider can't see each others' cookies.

Let's Encrypt has short-lived certificates, which are kinda useless and annoying when you have a device that is *not* a general-purpose computer capable of running their scripts.

What is the web server itself running on if not "a general-purpose computer"? If a special-purpose computer locked down to run only particular web server software, this particular web server software can include an ACME client. Certbot is not the only ACME client that can retrieve a certificate from Let's Encrypt or another ACME CA.

Am I really going to do a manual process on every cable modem, WAP, router, printer, switch, AP, IoT device, etc, every 3 months?

No. The manufacturer of "every cable modem, WAP, router, printer, switch, AP, IoT device, etc" will include an ACME client (or some other means of renewing a certificate) in the software package that runs the web server in said device.

The real problem is configuring which domain a device uses, as Let's Encrypt issues only 20 certificates per domain per week under a particular registrable domain based on Mozilla's Public Suffix List. And I'm told it takes months for a dynamic DNS host or other subdomain provider to get onto that list. But if you manufacture hardware devices or publish commercial software, as opposed to gratis software that a user can install on a generic computer, you can do what Plex did: become a reseller for some trusted CA to issue certificates for subdomains of your domain.

I'm actually wondering.With https://letsencrypt.org/ letting you automagically get a SSL cert that is trusted by the browsers without warnings wouldn't anyone with control over your domain be able to look good for most browsers?

run a dynamic dns name

Many domains used by dynamic DNS providers are still not on the Public Suffix List. If a domain is not on the Public Suffix List, Let's Encrypt won't issue more than 20 certificates in a 7-day period for subdomains of that domain. (Source: Let's Encrypt rate limits; Ratelimit for dyndns domain) Instead, the service will produce an error message to the effect:

Error: rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: no-ip.biz

This means 20 other customers of the same dynamic DNS provider are likely to have already obtained their certificates before you have a chance to.

run a dynamic dns name

Many domains used by dynamic DNS providers are still not on the Public Suffix List. If a domain is not on the Public Suffix List, Let's Encrypt won't issue more than 20 certificates in a 7-day period for subdomains of that domain. (Source: Let's Encrypt rate limits; Ratelimit for dyndns domain) Instead, the service will produce an error message to the effect:

Error: rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: no-ip.biz

This means 20 other customers of the same dynamic DNS provider are likely to have already obtained their certificates before you have a chance to.

I have some good news for you: you don't need to pay $15/year for an SSL cert. There is at least one CA providing certs for free, via a generic and open protocol called ACME.

A few years ago you would have had a point, but not today.

> Either way you are effectively stopped from using HTTP > unless you pony up to a CA and pay for more HTTPS certificates. Use Let's Encrypt for free certificates.

Similarly, BYOD on the home network should be segregated to an Internet-only guest wireless connection.

That wouldn't help if you want to let guests print to your printer or view videos on your NAS.

Your approved devices could get greater access, using your homebrewed CA certificates if you wish, but it's probably easier just to use Let's Encrypt.

How is "make and install your own certificates" practical when users bring their own devices, such as public library patrons bringing their laptops or phones to a branch or friends or relatives bringing their laptops or phones to someone's home?

BYOD wireless network is not part of the "internal network", it is part of the "public network". Managed library staff computers would be part of the "internal network" and could be configured with homebrew CA certificates.

The BYOD wireless "public network" would need certificates from a public CA recognized by the browser, like Let'sEncrypt.

Similarly, BYOD on the home network should be segregated to an Internet-only guest wireless connection. Your approved devices could get greater access, using your homebrewed CA certificates if you wish.

Don't want to be a network admin? Don't run a network.

There's no reason for skimping on your web server anymore, encryption is easy and even crappy virutal machines can serve up HTTPS without issue.

One reason is that your web server is private, and you don't own a domain.

In order to set up HTTPS traffic to the owner of a home router, printer, or NAS, its owner would first have to acquire a domain and a certificate for said device. But as I understand it, most providers of dynamic DNS on a subdomain without charge still aren't in the Public Suffix List. And if the domain in which your subdomain is registered hasn't completed the process to be added to the Public Suffix List, and 20 other customers on the same subdomain have already obtained a certificate from Let's Encrypt in the past week, Let's Encrypt will refuse to issue you a certificate on rate limit grounds. This means that even if you do buy a router, printer, and NAS with Let's Encrypt integration, you'll need to buy a domain for your home LAN and continue to renew it.

Why would video messaging need a server in the middle?

Because WebRTC is HTTPS-only, and getting a free certificate from Let's Encrypt requires buying a domain. A free subdomain from a dynamic DNS provider isn't enough because of the limit of 20 Let's Encrypt certificates per domain per week, which the dynamic DNS provider's other users have already used up.

There are quite a few free subdomain providers out there too, usually offering dyndns options and the like.

The problem is that a lot of these free subdomain providers aren't listed on the Public Suffix List. For example, afraid.org is not. And if a domain isn't on the Public Suffix List, Let's Encrypt issues no more than 20 certificates per week for that domain. This means 20 other users of that same domain will probably have already obtained their certificates before you, causing Let's Encrypt to reject your attempt to obtain a certificate with an error message to the effect:

Error: rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: no-ip.biz

So it appears to be either A. use Let's Encrypt for the certificate and pay for the domain or B. use a free subdomain provider for the domain and pay Namecheap for the certificate.

There are quite a few free subdomain providers out there too, usually offering dyndns options and the like.

The problem is that a lot of these free subdomain providers aren't listed on the Public Suffix List. For example, afraid.org is not. And if a domain isn't on the Public Suffix List, Let's Encrypt issues no more than 20 certificates per week for that domain. This means 20 other users of that same domain will probably have already obtained their certificates before you, causing Let's Encrypt to reject your attempt to obtain a certificate with an error message to the effect:

Error: rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: no-ip.biz

So it appears to be either A. use Let's Encrypt for the certificate and pay for the domain or B. use a free subdomain provider for the domain and pay Namecheap for the certificate.

You don't need to own a domain for Let's encrypt; controlling a subdomain is enough.

Only if the subdomain is a subdomain of a domain in the Public Suffix List. Let's Encrypt limits how many certificates may be issued per domain per 7 days:

The main limit is Certificates per Registered Domain, (20 per week). A registered domain is, generally speaking, the part of the domain you purchased from your domain name registrar. For instance, in the name www.example.com, the registered domain is example.com. In new.blog.example.co.uk, the registered domain is example.co.uk. We use the Public Suffix List to calculate the registered domain.

Because afraid.org is not in the Public Suffix List, no more than 20 certificates for subdomains of afraid.org will be issued in one week.

Seriously, how is this even an issue? You can get free certs and there's so countless walkthroughs on how to setup TLS for almost any server (with Mozilla's being the best imo). With ISP's consistently showing they have no respect for your content or anyone else's it's hard to justify NOT running TLS on a web server.

if you have control of the domain you can get a domain validated certificate. EFF's Let's Encrypt certificates use the ACME protocol to verify you have control of a domain: https://letsencrypt.org/docs/c...

You can get a free certificate from letsencrypt.

https://letsencrypt.org/certif... under the heading "Certificate Transparency"

True enough, I have renewed several times in the same day when setting up automation. 60/90 days seems like good default values for now with a concern to not overload the system for nothing. This is what is recommended here:
https://letsencrypt.org/2015/1...

Also 60/90 is fine for me because I always manually restart apache (apachectl restart) at least once a week so new certificates should always be loaded on time. I don't want the automated script to restart my server for stability concerns.

On a side note, most clients seem to have way to many dependencies. I found a pure bash one without any dependencies. Here it is:
https://github.com/srvrco/gets...

But anyway, Let's Encrypt certificate expire after 90 days, period.