Stories
Slash Boxes
Comments

SoylentNews is people

Meta
posted by NCommander on Monday April 17 2017, @06:20PM   Printer-friendly
from the removing-old-ciphers-is-like-taking-old-yeller-behind-the-barn-... dept.

In the continuing saga of website tinkering and people's love of update posts, I'm back with some backend configuration changes. Right now, things have been relatively quiet on the backend side of things. We've got some good news, and some bad news in this update. That being said, we've made a few small updates over the weekend. Rapid fire style, let's go through them:

CAA Records

CAA records define which certificate authorities (CAs) are allowed to sign your domains. They essentially act as a CA whitelist, and the most recent revisions of the Certificate Authority/Browser Baseline Requirements mandates that CAs check for CAA records and respect them. In line with this policy, we've white-listed Let's Encrypt and Gandi's CAs to issue certificates for SoylentNews for the time being as these are the two CAs currently in use here.

In a fun bit of fail, this is the second time I've tried to deploy CAA, and fortunately managed to succeed this go around. The problem stems from the fact that many versions of BIND except the very latest don't recognize the "CAA" record type, and cause the zone file to not process correctly if it's present. As we're still using an older version of BIND as our master server, I had to manually create TYPE257 records as seen below:

soylentnews.org. 3586 IN TYPE257 \# 16 0005697373756567616E64692E6E6574
soylentnews.org. 3586 IN TYPE257 \# 22 000569737375656C657473656E63727970742E6F7267
soylentnews.org. 3586 IN TYPE257 \# 35 0005696F6465666D61696C746F3A61646D696E40736F796C656E746E 6577732E6F7267
soylentnews.org. 3586 IN TYPE257 \# 12 0009697373756577696C643B

Both htbridge.com and ssllabs.com show that the CAA records are properly encoded, and show an additional green bar that they're in place.

Postfix LogJam

Almost two years ago, the Logjam attack on the DH key exchange was discovered and publicized. As part of our general hardening of SoylentNews, we regenerated all the DH parameters to prevent logjam from being a viable attack vector. Unfortunately, we overlooked the mail STARTTLS services on mail.soylentnews.org, and only caught it when I was checking various security things. The DH parameter files have been regenerated. Under normal circumstances, Logjam can't be exploited unless the underlying SSL cipher is relatively weak. As part of previous hardening, we kicked SSLv3 and many insecure ciphers to the curb, but unfortunately RSA_CBC_IDEA was accidentally left in place as a valid protocol for STARTTLS transport. Based on my understanding of the logjam attack, 1024-bit ciphers like RSA_CBC_IDEA are still difficult to exploit, and its likely only a nation state could successfully have breached it.

Given only SN staff have mail accounts, and that users are encouraged to change their passwords after creating an account, I think its safe to assume that we're relatively OK as far as data security and integrity go since email in general at best is opportunistically encrypted, and should always be assumed to be monitor-able (via a STRIPTLS attack). That being said, if you haven't changed your password from account creation though, it's likely a good idea to do so now.

We discovered our IMAP server has been serving a self-signed certificate during this check as well. We'll be replacing this with a properly signed certificate within the near future. I have other things on this topic that will be noted in a future post, so keep a look out for that.

Disabling HTTP Methods

A routine check of the site's security headers showed that we were accepting HTTP TRACE and other methods we don't need on production. The configuration for nginx has been modified to put a bullet in this behavior. We're still checking to make sure we got this everywhere, but we should be good on at least the production servers for now. This has bumped the site security rating up to an A on the HTBridge; we're still missing the referral security header, but we need to check to make sure there's no user impact before deploying it.

3DES Put Out To Pasture

As always in the world of encryption, various algorithms eventually become insecure and weakened as cryptanalysis gets more and more advanced. A few months ago, the SWEET32 attack against 3DES was discovered which drastically weakens the security of 3DES via the birthday paradox problem. In practice, SWEET32 requires a second exploit to even be usable as SoylentNews only allowed 3DES connections as a last resort if AES wasn't supported. As every major browser has supported AES for years, we decided to put 3DES out to pasture and have removed it from the allowed list of ciphers for SN.

Not too much to note in this round of administration games, but we're working to make overhaul changes to the stack to allow the potential for HPKP key pinning in the near future, as well as deploying TLSA/DANE support for both HTTPS and SMTP on SN. As part of this process, we'll also be enabling HSTS across subdomains, and reissuing our SSL certificates to enable OCSP Must-Staple. We'll keep you guys updated as we move towards that goal!

~ NCommander

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by NCommander on Monday April 17 2017, @09:53PM (8 children)

    by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Monday April 17 2017, @09:53PM (#495536) Homepage Journal

    I do security consulting and IT work on the side if you want me to assist you with getting A+ scores on your organization. See my email.

    I haven't played with Tomcat in several years, but if you check the SSLLabs report, as long as you have "TLS_FALLBACK_SCSV: True" enabled, and OCSP stapling as True in the "other" section below, HSTS will get you A+. CAA isn't very risky to deploy. At worst when you screw it up, you have to change DNS recorders before replacing your SSL certificates; it has no effect on path building for trust in X509, only on issuance on the CA side of things.

    --
    Still always moving
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by DannyB on Tuesday April 18 2017, @01:27PM (7 children)

    by DannyB (5839) Subscriber Badge on Tuesday April 18 2017, @01:27PM (#495827) Journal

    Thanks for the tip to get to the A+. Something I will work towards.

    I recently got my score up to an A. April 2016, a year ago, I got my score from a B up to an A-. But I had a B prior to that without ever having checked SSL Labs or trying to get that B score.

    The sad story is that when I pointed out DROWN and several F scores just over a year ago, the result was that DROWN was fixed on those servers and everything I can identify was upgraded to the point that it now gets a C. Those products aren't my responsibility, and so pointing it out was all I could do. I have no doubt that IIS servers could get an A or A+ if the people who run those had a goal to do so.

    I simply saw the SSL Labs score as a challenge and made it a side project or back burner project to improve from a B.

    --
    When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
    • (Score: 2) by NCommander on Tuesday April 18 2017, @06:39PM (6 children)

      by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Tuesday April 18 2017, @06:39PM (#495953) Homepage Journal

      The max limit for IIS is A due to lack of support for TLS_FALLBACK_SCSV (I ran into this with a customer recently). You could get rid of the DROWN problems by rekeying your servers you contract.

      --
      Still always moving
      • (Score: 2) by DannyB on Tuesday April 18 2017, @08:06PM

        by DannyB (5839) Subscriber Badge on Tuesday April 18 2017, @08:06PM (#495989) Journal

        Thank goodness that I never have and hopefully never will run IIS. But it is amusing to know that.

        --
        When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
      • (Score: 2) by DannyB on Tuesday April 18 2017, @08:26PM (4 children)

        by DannyB (5839) Subscriber Badge on Tuesday April 18 2017, @08:26PM (#495999) Journal

        The DROWN issue was that several products, including the one I work on, share a wildcard cert. Thus share the same private key. Some servers that I don't control were vulnerable to DROWN. I discovered it immediately when DROWN became news, and sent it up the chain of command. Things happened quickly.

        I had proposed that one possible way to make my product secure would be to spring for another cert with a different key.

        --
        When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
        • (Score: 2) by NCommander on Tuesday April 18 2017, @09:01PM (3 children)

          by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Tuesday April 18 2017, @09:01PM (#496012) Homepage Journal

          Generally if possible, I recommend against using wildcards and just issuing SSL certificates with multiple SANs if possible (this is easy with Lets Encrypt. YMMV with other things). Not always viable depending on your setup but wildcards can be a security risk in and of themselves since even if you have multiple wildcart certs protecting your tree. Once Lets Encrypt became a thing, we lost any need to have wildcards for SoylentNews and just have a hilariously long SAN list on Beryllium services.

          --
          Still always moving
          • (Score: 2) by DannyB on Tuesday April 18 2017, @10:03PM (2 children)

            by DannyB (5839) Subscriber Badge on Tuesday April 18 2017, @10:03PM (#496043) Journal

            Without a solid argument why to buy gobs of individual certs instead of one wildcard cert I would get nowhere. I have no doubt I could set up my server for Let's Encrypt. I don't know if that is the case for all other groups that operate servers. The environment I operate in is no doubt different than what you are doing at SN. If there is a solid security argument against wildcard certs, I would be very interested in that.

            --
            When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
            • (Score: 2) by NCommander on Tuesday April 18 2017, @10:44PM (1 child)

              by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Tuesday April 18 2017, @10:44PM (#496056) Homepage Journal

              The problem with wildcards is that they represent a considerably high risk factor. For example, imagine that you have www.example.com, mail.example.com, and payment.example.com, and you're in a PCI compliance setup so you've got everything that talks to the outside world living in the DMZ. You buy and deploy a wildcard certificate to all three of these domains to simply deployment and management.

              Now let's say your mail server gets compromised. They now have a valid wildcard certificate that would show the lock for payments.example.com. Depending on your network situation, if the attacker can MitM or change DNS records, he can now decrypt and decode everything going to your payments server even though it was isolated from the mail server because of the wildcard. If we're in a scenario where that the payment and mail server are on the same network segment, an ARP poison attack can easily allow a MITN if you can successfully pwn that mail server. Even beyond that, because most cases when working with wildcards you have the same private key on each box, if any box gets taken down, the attacker can recover the PK, and use it to decrypt SSL traffic in-flight over the network.

              There are technical reasons why SSL wildcards exist, specifically in cases where you can't know all the subdomains in general (i.e., dynamic subdomain generation is a valid case), but those should be few and far between. Wildcards are only really acceptable if they're absolutely necessary.

              This is part what EV certificates disallow wildcard issuance.

              --
              Still always moving
              • (Score: 2) by DannyB on Wednesday April 19 2017, @01:44PM

                by DannyB (5839) Subscriber Badge on Wednesday April 19 2017, @01:44PM (#496289) Journal

                That's a great argument. For anything processing payments, an individual EV certificate would be best.

                --
                When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.