Hacker News Reader

The only problem is if those subdomains have a password input field "somewhere" on their sites, AFAICT. Or are you referring to google's "later" plans to add a red exclamation point "insecure" flag to the url bar for all HTTP pages?

I'll admit when I first heard of them flagging HTTP password fields, my instinct was to write a little javascript to "mimic" password input field behavior (and store the real password away somewhere else, then at submit time, it sends in the correct data). But if it's just a tiny warning on the url bar, meh, not sure if I care...

Also note that https://letsencrypt.org appears to offer free CA certs.

Sephr was talking about wildcard certificates, which Let's Encrypt doesn't offer. But dynamically requested certificates can sometimes be used as a replacement for wildcard certificates.

I doubt most will even go that far. You can pretty much expect those that won't go HTTPS (for whatever reason, and there are many) to change their input type="password" fields to input type="text" fields.

That is probably what I am going to do for the internal site I maintain at work, since I can't get an SSL certificate for such a thing.

All this change is going to do is make password eavesdropping in person easier.

oh yeah text field, that's an interesting option and people might even use it as an easy work around [LOL]. I guess you could make the viewable size like 1 char then it won't be much worse than inputting it from a smart phone. Except for the large screen people can see from behind you LOL.

I guess people could do self signed certs that expire in "100 years" but you're right, even installing those can be super painful, and people may not go that far. Of course, initially what people will do is "nothing" and just let the insecure message appear, since it doesn't actually block any functionality seemingly...

If it's hosted in local IP space and therefore you can't get a certificate, you can setup a CA and push that CA certificate through Group Policy. I had to do it myself and it took 3-4 hours (mostly because I'm bad at Group Policy)

The problem is that I'm a developer on a team of six. And my site is used by another five or six teams. It's a little tools site that does various SQL queries and such against databases other teams don't have access to. They're not going to allow me to push my signing certificate onto everyone's computers. I'm very low on the org chart.

Well I assume in a companywith that many teams they would have already came across a need to manage their own simple, internal CA. Maybe you can be the person to set it up, trust me it's scarier than it looks

I'm not sure I'd call ~$50/year ( e.g. https://cheapsslsecurity.co.uk/comodo/positivessl-wildcard.h...) a "huge monetary subscription fee"....

I would. That's the same price as a year of hosting an entire VPS instance with 1TB bandwidth a month, 40GB SSD storage, and 512MB of RAM. And for what? A completely automated process that loads a page on your site, verifies a META tag is present, runs an openssl command, and prints the output to a webpage for you.

So for that $50, you can double all the specs on your server, or get a little green lock in your URL bar. And don't forget, we're not all in the US. I know a guy in Venezuela that doesn't have $50USD to spend on an SSL certificate.

I understand it costs money to run a CA. But if Let's Encrypt can run one for free, then surely so can Google, if they're so gung-ho on 100% of the web being over HTTPS. If you want that to be a reality too, you need to back free wildcard certificates. Otherwise you'll never be able to deprecate HTTP.

If you're running a commercial entity and $50/year is a problem for you, then I'd suggest that your business may have its challenges. Obviously it is (in most cases) possible to automate the cert creation process using let's encrypt for free, so it's a trade-off on whether the time it takes to do that is worth more or less than the $50 it'd cost to purchase a wildcard cert.

As to the compute power you can buy for that, it could be that says more about the cheapness of compute power than it does about the expense of SSL certs.

As to Let's encrypt running for free, well the post I was referring to indicated they didn't want to go that route, also you do know they're actively soliciting donations at the moment because, guess what, you can't run a CA for free...

> If you're running a commercial entity

Making the web open only to commercial entities is a huge problem by itself. I definitely would not want to make that a premise or assumption to participate in the Internet as an equal player.

I'm not. I'm running byuu.org without any ads, and without selling any products. I used to spend about 60 hours a week coding, nowadays it's more like 20 hours a week, and recoup only the occasional donation or licensing agreement (they reach out to me) for my software. If you were to weigh it against the hours I've put into things, I'm earning about $0.60 an hour for my work. And if you consider my own personal expenses on my projects, I'm at about -$30,000 in total. But I have fun doing it (occasional trolling aside), so it's worth the cost.

I wasn't willing to accept the Let's Encrypt limitations, and so I paid for a three-year AlphaSSL wildcard certificate for ... I believe $132 or so.

> As to the compute power you can buy for that, it could be that says more about the cheapness of compute power than it does about the expense of SSL certs.

Not really. There is absolutely no reason it should cost $5 to run openssl with a SAN of "www.byuu.org" and $50 to run openssl with a SAN of "*.byuu.org" -- the verification process is 100% identical for both.

That is 100% pure, unadulterated greed. They charge that rate because they can.

> because, guess what, you can't run a CA for free...

I know, the auditing fees are obscenely expensive and required every six months.

Google could afford it if they want the web to be 100% HTTPS. It wouldn't even be a drop in the bucket for them. It'd be a fraction of a sliver of a drop.

You're absolutely right. I'm surprised nobody here seems to care. I guess HN is popular with techies who have root access on their servers, or people who run commercial sites.

What happened to the hobby / non profit apps, blogs and forums that fill 90% of the web and my bookmarks? All of them have a login form somewhere. Tons of people already use secondary emails or throwaway emails, but these site owners now have to pay for SSL or have to upgrade their shared hosting to "business" or the like to get SSL included, or pay extra fees to install SSL.

If all they do is look for a password field that means pretty much any phpBB or wordpress blog out there is defacto "insecure" and the owners of those sites now need to find a way to get SSL on their (most likely)shared hosting. Mine is not free at all, it requires "installation" fees, plus "dedicated Ip" so in the end it cost near as much as just buying their SSL package.

At this point though it's very unclear how Google will find those "insecure" password fields. Does it honer the no-follow? Because last time I heard it's not useful to get a login form page indexed anyway.

> I'm surprised nobody here seems to care.

I'm going to get skewered alive for saying this, and I do believe their intentions were noble, but I honestly think Let's Encrypt has done a lot more harm than good.

It's completely deflated the opposition to the CA racket, but not given a comprehensive alternative.

There are servers that can't run certbot for a variety of reasons (including administrator policies that people running the webservers can't control.) The 90-day expiration is the most arduous of any CAs out there by far. Not only are there no wildcards, but there are strict limits on the number of subdomains you can register per week.

And if you don't like it ... too bad. There are zero free alternatives.

Most of us are hackers and can work around these limitations, but not everyone can. You can't expect most people to set up certbot, let alone write their own version. You can't expect them to build some system that automatically batches and registers new subdomains and maintains all those certificates.

> I guess HN is popular with techies who have root access on their servers

That's a lot of it as well. I'd go so far as to say the majority of internet sites out there (by number, not by traffic volume) are little commodity hosting firms that give you a web GUI version of an FTP client, and maybe if you're lucky charge you $10-20 a month for SSL as a checkbox feature in the payment options.

> At this point though it's very unclear how Google will find those "insecure" password fields.

It will probably just look for <input type=password> and if that exists, show the "Not Secure" message.

>Chrome will mark HTTP pages that collect passwords or credit cards as non-secure

Will probably get hated on, but you should shell out for your own domain if you're collecting this info - there are quite a few BYO domain, free hosts.

Zendesk, for example, has a Let's Encrypt-based system for all those <account>.zendesk.com pages. While it wouldn't be trivial to set it up, it is free and the information is out there if the admins of those sites want to make it possible.

Not everyone can get whitelisted from the domain creation limits of LE.

Unless you're creating [more than 20 new subdomains a week][1], you're not gonna hit that limit anyway. You can increase that figure to around 2,000 new subdomains a week if you're willing to include multiple subdomains per certificate; that should be more than enough for all but the largest of sites.

And even if you do need more:

> If you are a large hosting provider or organization working on a Let’s Encrypt integration, we have a rate limiting form that can be used to request a higher rate limit.

[1]: https://letsencrypt.org/docs/rate-limits/

If you want to have a signup process that takes less than 9 hours, you have a max of 20 new subdomains a week.

20 users signing up a week - likely with a retention of a few percent - is not a "large hosting provider".

You might have a few hundred users max, and already will be far over the rate limits.

Just start them off with HTTP and transparently upgrade to HTTPS after 9 hours. And if you're only retaining a small percentage of users who sign up, you can stretch that limit even further by only upgrading the users who you retain.

This isn't possible in a properly deployed HTTPS site, since it would already have an HSTS header with includeSubdomains.

> What are free sites that give every user a subdomain for their profile/site/etc supposed to do?

Couldn't you include an ACME request for a new subdomain certificate into the "create account" script?

This would certainly add some complexity (especially with automatically fulfilling the "proof-of-ownership" challanges and properly renewing all the subdomain certificates) but it seems doable with less running cost than a wildcart cert subscription.

Edit: On second thought, this does leak some interesting data to the CA - such as, how many users you have, what their usernames are and how your rate of new signups is.

>Couldn't you include an ACME request for a new subdomain certificate into the "create account" script?

If you're using Let's Encrypt that'd also limit you to 20 new users per week so I think you'd need a more complicated approach than that (or a different CA). Batching into groups might work but then user provisioning time increases. Wildcard certs do seem like the right way to go here, and the cost is pretty minimal

And that leak isn't constrained to the CA. Due to certificate transparency, that information is visible to anyone who cares to look for it.

AWS Certificate Manager will give you a free wildcard if your site is hosted behind Cloudfront or on an ELB.

I mean, those sites are insecure. Google has a responsibility to the user of the browser, not the site owner. If you want people to trust your site, you have to provide them the security to do so.

> What are free sites that give every user a subdomain for their profile/site/etc supposed to do?

Let's Encrypt and certbot. It's all but trivial to SSL your site and keep it up to date if you control the system.

Here's how I SSLed my blogs. This was interactive, but fully scripting it would be easy: https://rocknerd.co.uk/2016/12/04/rocknerd-is-now-fully-ssl-... Took me literally minutes to set up, it took more time to track down the http:// images to fix the mixed-content warning.

The entire argument is about sites where that is not possible.

Lets Encrypt has a limit of 20 domains per week for you.

So you end up with at most a few hundred users.

20 certificates per week, each cert can be for up to 100 subdomains via SANs; and that limit is only for new certs, renewals don't count towards it - so if you can batch your requests (eg, with an "it may take up to 12 hours for your site to become available over HTTPS" notice, then twice a day make one big cert request for all your new domains), you can get up to 2000 per week; and there's no hard limit to the number you can accumulate over time.

https://letsencrypt.org/docs/rate-limits/

If that's not enough for your use case, you're probably big enough that a wildcard cert is a negligible expense.

No site should require a day's delay on an automated software thing that can be done in seconds. The limit remains at 20 per week if you want to provide a good experience. And that's not big.

Sure, it's not ideal... but does it really matter? Just register your domain with this hypothetical service while you're still preparing the content for it, so there's time for the cert to go through before you need it. Or they could let you provide your own cert if you're in that much of a hurry.

We're talking about edge-cases within edge-cases at this point: a service that (1) offers HTTPS subdomains (2) hasn't been able to get a rate-limit increase from Let's Encrypt (3) is unwilling to buy a wildcard cert (4) either is growing by hundreds of subdomains a day, or has a significant amount of clients who can't wait a few hours for a cert but won't buy their own. That's so oddly specific, I'm not surprised people aren't going out of their way to cater to it.

That's so oddly specific, it's basically every hosted solution you could invent, ever.

If I want to build my own little Github sites, I'd already run into the problem.

And, in fact, I've run into the limits several times before, and had to use startssl certs for far longer than planned because of that.