Easiest way to use Let's Encrypt

Help
21

There is a reason for that data, it’s not unreasonable. The reason is you don’t know or can’t learn how to upload files to your own website. If an app asks for permission for your camera to take a picture for a photo sharing app, it’s not unreasonable just because it can possibly be used to spy. If you don’t want to give permission then you can use another camera app and just upload the photo. How about I put manual verification first before automatic verification? Would that be better?

There is FTPS and SFTP if they are worried about the connection which I recommended. There is always a balance between accessibility and security. Some servers don’t have FTPS or SFTP, if they all did I would only have secure FTP options available.

Trust is very subjective. I wouldn’t trust Sony with my data but others do.

22

I think what’s best is to contribute to make their client better for old Windows computers. They had a closed Beta for awhile before Public Beta which can be considered alpha testing.

LE did fulfill their promises by offering a free, automated, and open CA. The client was really extra work. Let’s Encrypt is doing a lot for everyone, and as programmers we shouldn’t be complaining but rather contributing.

23

sjdfnldas, If you want people to trust your website, you have to be transparent. That means that you must have a page on it that gives all the details of what you have done (except for your own passwords and code) so that experts in cryptography, servers, and other disciplines related to LE can evaluate what you have done. If you don’t provide transparency, then all your promises, claims, and boasting will mean nothing. In a world filled with malicious users, we must assume that your purported solution is, in actuality, a disaster waiting to happen. This is not a personal aspersion, as I know nothing about you personally (including your name). It is a necessary defensive and sensible position we must have by default, when there is no transparency. And I second the complete objection to your use of Whois privacy and anonymity. It is suspicious on the face of it. I might relent if there were verifiable transparency.

24

I appreciate your opinion. Once I have the update out that uses the Web Cryptography API you can view the source yourself and see if you trust it. The Web Cryptography API was made by experts and has gone through rigorous open testing.

25

sjdfnldas, Errors in uploading files automatically is only one class of errors. Since most people (including you and me) do not have the experience to know of all possible error conditions or messages, thorough private then public testing is required for any networking or systems management product. Limiting the discussion to one type of error is not going to protect you from the criticism of experienced engineers.

Specifically, you are welcome to use secure FTP in a client, but the same requirements apply, including that the user must not see error messages.

Trust is not just subjective. Determining whether a product meets its goals is difficult, but determining that a product does not meet its goals is not so hard, since only one counter-case must be found. And both engineers and users are good at finding such cases.

The larger issue is that claims like yours must be backed up by full transparency.

26

As I said, Python (and other Linux-mainly technology) are a great choice for a proof-of-concept or rapid development prototype that is never seen by the public. No professional engineer would allow such a product to leave the building.

LE did not fulfill our promise to provide an easy, care-free, and automatic way to make any website into an HTTPS website. We should not have declared Beta. Becoming a trusted CA is only one of the required tasks. It is not sufficient. As programmers we have a responsibility to complain whenever we see something wrong (defined as compromising our project goals). If a company would fire me for complaining about something wrong, I would be glad to leave that company. As to your final point, those who have the ability and time should contribute, definitely not everyone. Your failure to understand such points is troubling.

27

As I stated before it would best if you could contribute if not then please direct your LE complaints at the developer group. I never said there anything wrong with complaining but if you find something wrong and can fix it, that would help yourself and everyone else.

I’m finished with this discussion. There is no point in going back and forth here as it solves nothing

28

Anyone can complain. That takes zero effort and accomplishes nothing.

As programmers we have a responsibility to help, not complain. That is the spirit of free open source software.

3 Likes
29

codinghorror, A project as potentially large as LE involves many levels of work, including coding, determining overall strategy, legal issues, writing for the public, writing for users, monitoring error reports, monitoring articles about LE on the Web, and much else. Nobody is good at all of this!

If we view our range of contribution levels as “coders only”, and mandate a policy of “everyone help as much as you can”, then we’re back to the Hacker mentality of the good old days that produced much tangled software that couldn’t easily be extended or be bug-fixed.

If we were to go to an extreme, and mandate no complaining (deleting all complaints that might appear), imagine the result. One thing would be for sure, software would be of low quality, if for no other reason than because the end users would have little or no input into the process.

A project like LE would surely fail if it were built bottom-up, by coders only.

Every contributor to a significant-sized project has basic responsibilities: ensuring their code is of high quality, fulfills the requirements and design documents, is compatible with (looks like) others’ code, and raises flags (complains nicely) when something is going wrong, All of these tasks and more are of higher priority than coding.

That is the message I tell you based on 40 years of professional programming, and you can also read it in the extensive literature on how to conduct a large project.

It is not true that “anyone can complain”. Only experienced engineers can reliably detect faults in the process, in the requirements, in the design, in the coding, or in the quality assurance. Of course, I’m talking about high-quality comments, which matter to the project, not complaints about politicians or other wasting of time.

I am surprised I have to say these things (which are obvious, to me) to someone who is part of the “discourse staff” here, and if my input is not appreciated here, I’ll just fall silent at this point.

30

And the reason for phishing sites to ask your bank details is they like to have your money. You just don't get it, either deliberately or out of genuine ignorance.

You shouldn't be handling anyone's data. Period.

So again: Entering your hosting credentials into any third party website is a complete no-go. Any website asking for it is not to be trusted, especially if it hides behind Whois protection.

You can act all innocent as you want. At the very least it shows that you have given this way too little thought. At worst you're phishing off people's credentials. This is the Internet, so let's assume the latter.

31

I'm not surprised at all. Much open source and smaller projects are pioneered by engineers with an idealistic chip on their shoulder resulting in a very narrow view.

32

I am surprised you typed a thousand words defending your “right to complain”. One wonders if there might be a more productive, constructive way to spend that time.

1 Like
33

There certainly would be if it weren't for some people needing simple concepts explained to them in verbose detail.

34

Hey Jeff, really cool to see you. Big fan of your work. Honestly I think it’s best to end the discussion here. It’s obvious no one is going to change views in any way shape or form. Besides that what are you working on nowadays? I got time to contribute to some meaningful things (other then discourse because I’m crap with Ruby).

David can complain about the client with the LE dev group, please let him be.

NOYB, if you’re going to contribute to a debate be constructive. Your responses do nothing but provoke. Your not involved at all.

TCM, I removed the FTP. It’s too much work for me to maintain with many different directory structures that I have to add for others. I would rather not do the work with ungrateful people like you out there. If I wanted to do phishing I wouldn’t offer another option.

Everyone else, the private key is now generated on the client side and never transferred at all by default.

It’s ridiculous how negative this community can be, especially seeing the previous 90 lifetime day debate forum discussion.

35

Thanks for the conformation.

36

Actually, I’m going to leave it in. I’m not going to let someone that doesn’t even trust his own browser to generate a private key to ruin it for everyone else.

37

You simply don't understand the trust model involved. At all. And throwing a tantrum isn't going to get anyone to say "Awww, the poor sjdfnldas had his feelings hurts. Maybe some unwarranted trust will cheer him up."

The Internet doesn't care about your feelings. You gain trust by not appearing shady. It's as simple as that. And you're not doing it at all.

1 Like
38

I would certainly agree that any process where you end up disclosing the private key to third parties should be avoided, considering that the CSR would suffice (see https://gethttpsforfree.com/). “Disclosing to third parties” to me includes scenarios where the client might be generated client-side, but there’s no way to verify this without auditing the entire code base (and making sure you’re actually being served what you were auditing).

That being said, this is something that other CAs do too (e.g. StartSSL - and yes, that’s not a 1:1 comparison since this is a “random” site), so I wouldn’t be too harsh about it. I would at least add an option to provide a CSR and only optionally allow the private key to be generated in the browser (after appropriate warnings).

With regards to the discussion about the client being written in Python: I think it’s a good choice for Linux, which runs the majority of web servers. As for Windows, the deployment story there might not be as good, but it’s certainly possible to run python on Windows. The decision to focus on Linux support, and support for apache and nginx initially absolutely makes sense given the market share of those stacks. Luckily, ACME doesn’t have any lock-ins with regards to operating systems or web servers, so there are plenty of third-party clients with better support for Windows, written in languages that are more easy to deploy on Windows, and that support typical Windows environments way better (i.e. IIS). It would be silly to implement the official client in a .NET language, which is comparatively harder to deploy on the most commonly used OS for web servers.

1 Like
39

I would certainly agree that any process where you end up disclosing the private key to third parties should be avoided

Agreed I received this feedback from a couple people. So that is why I have updated it to generate it completely on the client side with no disclosure at all. Anyone can view the key generation source and audit it themselves.

40

Please look up the definition of tantrum. People keep wanting help getting the FTP to work for their directory structure and I only have so much time to help them. It’s harder to help them with people (actually one person) that don’t even want FTP there. Removing FTP would save me time in support so I took it out. Then I got feedback from people saying how convenient and useful it was so I put it back in. If more people come out and tell me to remove FTP I will.

If you don’t trust the service don’t use it. I don’t care about gaining your trust. Hopefully you learn to trust your browser one day.

Don’t expect any further replies from me unless you have useful feedback.