> On 2016-05-10, Kevin Chadwick <m8il1i...@gmail.com> wrote: > >> > Also, after you generate and sign the certificate, you don't have > >> > to keep the script. > >> > >> Validity on the letsencrypt CA is 90 days max. (Partly to restrict > >> usefulness of a bad cert because they don't do CRLs, which are pretty > >> much useless anyway, and partly to encourage users to automate). > > > > Ugghhh, I was fearing that their automate and security mantra might > > clash, but they don't seem to mention it up front. 365 days already > > annoys me especially as I intend to use OpenSSH for anything > > particularly important and cryptanalysis is not a problem for years on > > a low traffic site. > > It's not about cryptanalysis, it's about reducing impact from > compromised hosts and from the weak authentication systems that are done > on all the "low value" DV CAs. (specifically this one is "requester had > access to cause files to be served at an http server running at the > address pointed to by DNS at the time it was requested" so a security > failure at any of a number of points would allow access). >
Yeah but all I give them is an CSR. I haven't had an issue like that before with STARTSSL. I agree the CA system is ridiculous though and was disappointed when I found letsencrypt's policy documented showed it to largely be a copy of all that has gone before rather than something revolutionary. I guess without DNSSEC being fixed and widely used or DNSCURVE being widely used or major browsers getting directly involved in domain validation (really the only important thing) then that can't happen. > > You enforce SSL for data submissions, a user checking keys has to check > > the domain in any case and hope the browser domain matching code is > > secure too (yes there has been atleast one firefox bug there) even > > before considering the DNS system. > > Still, browsers are a higher bar than the control panels and front line > support staff at a typical cheap domain host. > Agreed, and non gpg'd emails especially. > > It's main unrealised potential benefit is; add *some* security by > > default to all those insecure wordpress logins. > > That's a terrible reason. And actually it's "make those insecure > CMS sites look more like they might be secure" when they're no > such thing. Because people have been trained into equating https > with security. Which is just plain wrong. > Well yes but more pop up everyday. I have a friend who paid good money for a site and because I didn't want to send passwords by text message or email and enabled SSL on the wordpress login (for free simply because I couldn't allow it!!!) I was asked by the web developer company if I worked for the CIA or something!! Later they changed the password on me to something quite simple!! Interestingly, a few months later the wordpress admin login went down at heart internet and login attempt restrictions put on them all because wordpress sites were being widely brute forced apparently in order to add them as attractive (high upload bandwidth) clients in botnets. -- KISSIS - Keep It Simple So It's Securable
