Replicant

https://www.ssllabs.com/ssltest/analyze.html?d=replicant.us

I would say, as you wrote: "An additional root certificate may need to be imported."

Just go here: http://www.cacert.org/index.php?id=3
grab this CAcert root certificate: Class 3 PKI Key > Intermediate Certificate (PEM Format) and import it to your browser.
Depending on operating system- and browser there are different ways to do that; but I'm sure the search engine of you choice will find every combination シ

http://www.startssl.com/ is also issuing free SSL certifiates and there are included in almost all browsers.

I can't find this discussion. Could you please link it to me?

I can't find this discussion. Could you please link it to me?

I think this thread is what Paul means: http://redmine.replicant.us/boards/33/topics/5199?r=5889#message-5889

great news! I spoke with Ramereth from the #OSUOSL freenode room and they started fixing our TLS cyphers so that we now get an A rating at ssllabs for some of our subdomains. I think that blog.replicant.us and redmine.replicant.us are both now getting B ratings instead of C ratings. This is a good start!

Ramereth said the following:

"we probably should look at moving blog.replicant.us to one of our new hosts soon. it would be more work to get that rating higher due to the machine it's on."

"we support any cert that works with apache. we just need a key and cert. just send us a ticket to do it. Let's encrypt is more complicated as we need to work out the automation part and how it interacts with our systems. but we're working on resolving that in the next few months, hopefully by summer if not sooner. I mean, we can install the cert, but we'd have to change it every 90 days.. just send an email to support@osuosl.org with the details. we'll likely want to find a way to copy the private key securely and not via email."

So, are we in agreement that we should move away from CACert and get one cert that includes all our subdomains? If so, I think Let's Encrypt and https://www.globalsign.com/en/ssl/ssl-open-source/ are two good free options. What are all the subdomains that we have right now? Here's my best guess of an exhaustive list:

redmine.replicant.us
blog.replicant.us
www.replicant.us

git.replicant.us already has an A+ rating, probably thanks to Wolfgang, so I'm assuming we can leave that one be.

If we go this route, are we also in agreement that we should ask that all of our http traffic get redirected to https?

Wolfgang: If you agree to moving forward with a non-CACert cert, do you want to make it or would you rather I do it? I've done this a few times before and think I can make it happen.

Kurtis Hanna wrote:

So, are we in agreement that we should move away from CACert and get one cert that includes all our subdomains? If so, I think Let's Encrypt and https://www.globalsign.com/en/ssl/ssl-open-source/ are two good free options.

I definitely support doing this. While Let's Encrypt is great, the 90-day expiration period makes it basically unusable unless OSUOSL installs the automation software. Since it sounds like OSUOSL can't do that immediately, I'd suggest going with GlobalSign -- I've had brief interaction with their customer service and they're very helpful, flexible, and responsive. After the GlobalSign cert eventually expires, re-evaluating whether to move to Let's Encrypt at that point may be a good idea.

What are all the subdomains that we have right now? Here's my best guess of an exhaustive list

The following Startpage query suggests that the 4 subdomains you list are the only ones in service:

replicant -"powered by redmine" -"Proudly powered by free software: PHP, Bootstrap, SimplePie, Lightbox" -"Proudly powered by WordPress" -"GitLab" site:replicant.us

If we go this route, are we also in agreement that we should ask that all of our http traffic get redirected to https?

My inclination would be to wait a month or so to verify that HTTPS is working properly, then start redirecting HTTP to HTTPS, then if everything is still working properly after another month, add HSTS.

As a side note: SSL Labs is a great tool, but it's not the only one out there. I'm quite fond of Mozilla Observatory, which can also detect security-relevant misconfigurations in the HTTP headers in addition to the TLS implementation. Once Replicant is passing SSL Labs with flying colors, you might consider starting to address the issues raised in Mozilla Observatory.

Great to see that this is getting attention. Cheers!

Relatedly, quoting myself on IRC on Feb 22 2017:

if it helps with the certificate issues, there's a good chance that I'm okay with donating circa 20 USD (in Bitcoin) to the Replicant project, contingent on the website moving to Let's Encrypt.

That bounty still stands, and I also extend the bounty to cover a GlobalSign Open-Source cert given that it looks like waiting for Let's Encrypt would delay things.

There is another problem with the CAcert certificate. It appears that the root cert is signed using MD5 as signature algorithm. Firefox shows the following error message:

The certificate is not trusted because it was signed using a signature algorithm that was disabled because that algorithm is not secure.
Error code: SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED

Generating a new CAcert wildcard certificate for replicant.us likely solves this problem, but I don't think it's worth it spending time on this. We should look to get better options working.

Jeremy, thanks for the bounty offer!

OSUOSL is able to use letsencrypt right now. they just don't have their renewal automation set up, and would have to renew the cert after 90 days. they are saying that they plan on getting automatical renewal of letsencrypt certs working within a few months, which would be before our first required renewal.

are you able to expand the git.replicant.us cert to include 'www.' 'redmine.' and 'blog.' and plain ol' replicant.us and then send the new cert to support@osuosl.org?

i messaged Paul and Ramereth on IRC earlier today but haven't heard back from either of them yet. i think that migrating to a new host is a seperate issue, expecially if you are able to expand the letsencrypt git.replicant cert to include all the other subdomains and replicant.us right now.

what do you think about this as a short term option? https://www.godaddy.com/ssl/ssl-open-source.aspx

It doesn't seem to have any strings attached. I agree that the globalsign requirement that it is "Not be a site that is also used for commercial purposes" could be problematic.

Kurtis Hanna wrote:

are you able to expand the git.replicant.us cert to include 'www.' 'redmine.' and 'blog.' and plain ol' replicant.us and then send the new cert to support@osuosl.org?

i messaged Paul and Ramereth on IRC earlier today but haven't heard back from either of them yet. i think that migrating to a new host is a seperate issue, expecially if you are able to expand the letsencrypt git.replicant cert to include all the other subdomains and replicant.us right now.

No, I don't think that I'm able to do this. You need to prove ownership of the domain in some way and in the case of Let's Encrypt, this is difficult or even impossible with our current setup. I can't simply request a cert for other subdomains from a host that only serves one subdomain.

what do you think about this as a short term option? https://www.godaddy.com/ssl/ssl-open-source.aspx

Looks good. Do you know if such a cert can cover multiple subdomains or if it can be a wildcard cert?

Wolfgang Wiedmeyer wrote:

I don't like the requirements for the free cert at GlobalSign, especially the non-commercial clause as this is always open for interpretation.

I had an email exchange with GlobalSign in 2015 about this (in the context of getting a cert for https://www.namecoin.org/ ). Here's what Gregory Tomko from GlobalSign told me at the time:

Just double checked with my manager and yeah you guys should be approved for a free cert. Basically as long as you're not selling the software, it's all good. It's fine for financial transactions to be involved (cryptocurrency or otherwise) as long as it's not for purchase of the software itself.

I don't know whether that's still their current policy, but anyway I hope this info helps inform the decision-making process.

Cheers!

Kurtis Hanna wrote:

what do you think about this as a short term option? https://www.godaddy.com/ssl/ssl-open-source.aspx

It doesn't seem to have any strings attached.

It looks like that offer is only valid for the first year, which to my knowledge is not the case for GlobalSign. It sounds like Replicant is planning to switch to Let's Encrypt within a year anyway, so this might not be a problem -- but it definitely does qualify as a "string attached" that should be considered.

I just checked with OSUOSL and they are ready to update redmine for us! We just need to change a DNS setting, which I hope happens in the next few days. After speaking with Paul, it sounds like a migration off of OSUOSL might take a little while.

So, I propose we get a new cert. I personally don't have a preference where we get it from. Wolfgang, do you prefer GoDaddy, GlobalSign, or some other option like https://www.sslforfree.com/ ? Would you like Jeremy to email GlobalSign again and request that they give Replicant an official green light, in the same way as they did with NameCoin?

I tried calling GoDaddy to ask if they support multiple sites. Their wait time was too long for me to be able to get through. I'll try again.

https://www.sslforfree.com is something I randomly found during an internet search. I don't know how reputable they are, but they do support multiple domains. Maybe there are other options like this one out there.

Wolfgang Wiedmeyer wrote:

The ftp server only has a B rating because of enabled RC4 ciphers. I guess that this was done intentionally for backwards compatibility and I don't see this as a big issue.

FYI, ciphersuite downgrade attacks are a thing (there have been some high-profile attacks discovered recently), so unless there is a very strong reason why RC4 needs to be supported, I would recommend disabling the RC4 ciphersuites.

Cheers!

Kurtis Hanna wrote:

https://www.sslforfree.com is something I randomly found during an internet search. I don't know how reputable they are, but they do support multiple domains. Maybe there are other options like this one out there.

I recommend staying away from this. A quick Startpage search turned up this thread: https://community.letsencrypt.org/t/easiest-way-to-use-lets-encrypt/7633 . In which the main developer admits that his website has access to your private key, but he promises not to abuse that privilege. Dangerous as hell.

EDIT: Not only does he admit that he has access to your private key, he doesn't seem to think this is a big deal, which raises severe concerns about his competence to be handling anything related to TLS.

Jeremy Rand wrote:

Wolfgang Wiedmeyer wrote:

The ftp server only has a B rating because of enabled RC4 ciphers. I guess that this was done intentionally for backwards compatibility and I don't see this as a big issue.

FYI, ciphersuite downgrade attacks are a thing (there have been some high-profile attacks discovered recently), so unless there is a very strong reason why RC4 needs to be supported, I would recommend disabling the RC4 ciphersuites.

Yes, they are, but the downgrade attacks need to be prevented on the client side, anyway. That's why I don't see it as a big issue.

Kurtis Hanna wrote:

I just checked with OSUOSL and they are ready to update redmine for us! We just need to change a DNS setting, which I hope happens in the next few days. After speaking with Paul, it sounds like a migration off of OSUOSL might take a little while.

Ok, are Paul and Denis aware of the needed DNS change? I hope there is not much downtime and the upgrade works without issues.

So, I propose we get a new cert. I personally don't have a preference where we get it from. Wolfgang, do you prefer GoDaddy, GlobalSign, or some other option like https://www.sslforfree.com/ ? Would you like Jeremy to email GlobalSign again and request that they give Replicant an official green light, in the same way as they did with NameCoin?

I agree with Jeremy regarding sslforfree. And they use ACME, just like every Let's Encrypt client, so from my understanding, there is nothing they can do we can't do ourselves.
I'd prefer GoDaddy, given that we get a cert that is valid for all needed domains. I guess multiple certs (one for each domain) would be fine, too. If we can only get one cert for one domain, I'd still consider it and then use it for the Redmine instance. I also think that the one year limit is no issue. Either OSUOSL should have full support for Let's Encrypt by then or we should be able to move away from OSUOSL until then.

I'm still not sure about GlobalSign. I just find it ridiculous to get a distribution restriction indirectly imposed by the certificate authority. Even if it may never affect us, they still could pull the cert at any point, e.g. just because they don't like that we recommend Tehnoetic on the website. Jeremy, feel free to contact them about this, but I'd also like to hear Paul's and Denis' opinion on this.

I just checked and Replicant's DNS is handled by Gandi. They have SSL certificate offers for domain registrations: https://www.gandi.net/ssl
It looks like we are not eligible for a free cert, but afair Debian had certs from them in the past before they switched to Let's Encrypt. Maybe they are willing to provide a free cert for a free software project like Replicant.

Thank you guys for working on this!

There is also the issue that http is not redirected to https on the mailing list host at lists.osuosl.org, so passwords and other personal data can be intercepted in the online forms. Kurtis already mentioned this in the Redmine upgrade ticket, but it may be necessary to open a separate ticket about this.
I just add this as a reminder, in case we need to act on this again.

Wolfgang Wiedmeyer wrote:

Jeremy Rand wrote:

Wolfgang Wiedmeyer wrote:

The ftp server only has a B rating because of enabled RC4 ciphers. I guess that this was done intentionally for backwards compatibility and I don't see this as a big issue.

FYI, ciphersuite downgrade attacks are a thing (there have been some high-profile attacks discovered recently), so unless there is a very strong reason why RC4 needs to be supported, I would recommend disabling the RC4 ciphersuites.

Yes, they are, but the downgrade attacks need to be prevented on the client side, anyway. That's why I don't see it as a big issue.

My understanding is that usually TLS downgrade attacks can be prevented if either the client or the server doesn't support the insecure ciphersuite, but there are weird cases where only the server can prevent the downgrade. Logjam is an example of this, see https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf . Given these issues, unless there is a specific reason why RC4 is needed (it sounds like there isn't), I still strongly recommend disabling the RC4 ciphersuites server-side.

Wolfgang Wiedmeyer wrote:

I'm still not sure about GlobalSign. I just find it ridiculous to get a distribution restriction indirectly imposed by the certificate authority. Even if it may never affect us, they still could pull the cert at any point, e.g. just because they don't like that we recommend Tehnoetic on the website. Jeremy, feel free to contact them about this, but I'd also like to hear Paul's and Denis' opinion on this.

I've contacted GlobalSign, and everything sounds good pending a reply from Pedro. @Kurtis/Wolfgang, have you received any confirmation from Pedro at GlobalSign? (I haven't seen any emails on that thread since the April 7 emails from Greg.)

Jeremy Rand wrote:

My understanding is that usually TLS downgrade attacks can be prevented if either the client or the server doesn't support the insecure ciphersuite, but there are weird cases where only the server can prevent the downgrade. Logjam is an example of this, see https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf . Given these issues, unless there is a specific reason why RC4 is needed (it sounds like there isn't), I still strongly recommend disabling the RC4 ciphersuites server-side.

Agreed. It's a non-issue when it's fixed on the client, but if it isn't, it would indeed be good to have this fixed on the server. It's not fixed for Replicant 4.2 users as the patches I submitted for fixing this were never part of images. So yes, this should definitely be part of a ticket about the ssl server config. GlobalSign lists having an A rating as a requirement for the cert, so we may be required to get this fixed anyway.

I also didn't yet get a mail from Pedro.

The GlobalSign cert is now in place for redmine, blog and website. The redirect is still missing. This is somewhat tracked in #1323.
It would be nice to additionally have HSTS, at least for redmine.

I am willing to communicate to OSUOSL about HSTS, but I'm not very familiar with this and am not sure what to ask them. Please feel free to either contact them yourselves, or let me know what to ask and I'll contact them about this.

On a related note, would we need to ask Denis or Paul to modify the CAA DNS record? I'm also not super familiar with this and don't know what to ask them.

Kurtis Hanna wrote:

I am willing to communicate to OSUOSL about HSTS, but I'm not very familiar with this and am not sure what to ask them. Please feel free to either contact them yourselves, or let me know what to ask and I'll contact them about this.

The issue with HSTS is that once HSTS is enabled, if Replicant's TLS certificate gets revoked or expired, the affected Replicant website domains will be inaccessible (you won't even be able to click through a warning to access the site) until the HSTS header expires or a new certificate is put in place. That new certificate would need to be trusted by browsers, so CACert or self-signed aren't an option. So, in practice, this means that we need to do one of the following (in descending order of security):

1. Be willing to purchase a commercial CA-issued certificate in the event that GlobalSign's cert is revoked or expires.
2. Use HSTS with a sufficiently short expiration period that the downtime caused by a hypothetical revocation or expiration of the GlobalSign cert would be considered acceptable.
3. Wait for OSUOSL to support Let's Encrypt, so that we can switch to Let's Encrypt in the event that GlobalSign's cert is revoked or expires.

I think it's unlikely that GlobalSign's cert will be revoked or be banned from renewal, but it's important to consider the ramifications of such an event (despite it being unlikely).

So, the questions are: is the Replicant project willing to commit to buying a commercial CA-issued cert if that happens, and if not, how much downtime is "acceptable" if that event happens? The recommended expiration period for HSTS (if high security is desired) is 2 years, which obviously is not acceptable downtime if the cert goes bad. Obviously any expiration period for HSTS is more secure than the status quo (0 seconds), but committing to buying a cert in that event will enable you to have much better security than if you choose a short expiration period.

Let me know what you guys want to do, and I can then tell you what to ask OSUOSL for.

On a related note, would we need to ask Denis or Paul to modify the CAA DNS record? I'm also not super familiar with this and don't know what to ask them.

In my opinion, CAA is less important than HSTS, so if the same people would need to be involved in both tasks, let's worry about HSTS first. If we can parallelize them, let me know and I'll look into CAA.

Cheers!

Just last weekend, I had an issue with HSTS on the Replicant Git host. The Let's Encrypt update didn't work because I had misconfigured Gitlab (the config only accepts one custom Nginx config change and not several). So the cert had expired and HSTS prevented connecting to the server which made fixing the issue a little harder.

Unexpected things can happen and in this case, the consequences would be quite fatal if a lot of users cannot access Replicant's websites anymore. So I tend to not add HSTS for now until the situation is more clear. If OSUOSL has Let's Encrypt available, we can ask them to enable HSTS in the process of switching to Let's Encrypt. Otherwise, max-age could be set for a period that expires when the current cert expires, but I don't think this is worth the risk.

Jeremy Rand wrote:

Relatedly, quoting myself on IRC on Feb 22 2017:

if it helps with the certificate issues, there's a good chance that I'm okay with donating circa 20 USD (in Bitcoin) to the Replicant project, contingent on the website moving to Let's Encrypt.

That bounty still stands, and I also extend the bounty to cover a GlobalSign Open-Source cert given that it looks like waiting for Let's Encrypt would delay things.

Bounty sent.

Should we keep this open? The originally reported issue is now solved and the issue is already quite crowded. If you want track SSL-related issues with the Replicant infrastructure, opening a new issue for them probably makes more sense.

Wolfgang Wiedmeyer wrote:

Should we keep this open? The originally reported issue is now solved and the issue is already quite crowded. If you want track SSL-related issues with the Replicant infrastructure, opening a new issue for them probably makes more sense.

I agree. I suggest closing this issue and creating new issues for HSTS and CAA.