Articles tagged with TLS
-
-
A year ago we had an issue using Git from TeamCity “JSchException: Algorithm negotiation fail” due to
diffie-hellman-group-exchange-sha256wasn’t supported. (see Git connection fails due to unsupported key exchange algorithm on JetBrains issue tracker)Today we had a similar issue with using the TeamCity plugin for RubyMine.
Our TeamCity installation is served through a reverse proxy by an Apache web server. The only common algorithm between Java and our TLS configuration isTLS_DHE_RSA_WITH_AES_128_CBC_SHA.Due to Java’s JCE provider having a key size upper limit of 1024, since Java 8 it is 2048, the connection fails because we require at least 4096. In RubyMine you get the Message “Login error: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive)”.
-
To fix this on a Debian “Jessie” 8 system with OpenJDK 8 installed follow these steps.
Install the Bouncy Castle Provider:
sudo aptitude install libbcprov-java
Link the JAR in your JRE:
sudo ln -s /usr/share/java/bcprov.jar /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/bcprov.jar
Modify the configuration
/etc/java-8-openjdk/security/java.securitysecurity.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider
-
-
-
As GodObject was affected by the OpenSSL Heartbleed bug, we used this as a chance to reevaluate our TLS setup and discovered a possibly dangerous oddity in how our preferred certificate authority StartSSL handles authentication to their account management web interface.
To acquire X.509 certificates which are trusted by a wide range of browsers and other communication partners we use the certificate authority service StartSSL (run by the Israel based company StartCom) for serveral years now. StartSSL is our choice because they are far less expensive than other CAs and at the same time offer very good customer support via Jabber (XMPP) instant messaging, even outside normal working hours.
When looking at our affected certificates which were issued by the StartSSL intermediate CA for servers of paying customers (class 2) I realized that their EKU extension tagging allows using them also on the client side of a TLS session. Typically this is a good thing because systems like SMTP or XMPP daemons act both in the role of client and server.
Now if you want to be customer of StartCom’s service you need to create an account. Using this account you can manage your personal details and credit card information, validate your domains and email addresses, request validations, request and revoke certificates and possibly more. Some of these actions are free and some cost money.
To manage this account you receive a free certificate signed by StartSSL intermediate CA for clients which is tagged to only be used as client in TLS through the EKU extension. This certificate is installed in your browser and is used for authentication in HTTPS.
Because in X.509 you normally can only trust a root CA and not only specific intermediate CAs I asked myself if maybe every client certificate issued by StartSSL can be used to manage the account. After our certificates had been revoked and replaced, I tested this theory with one of our new certificates and was actually able to log into my StartSSL account.
As far as I see it, this means every class 2 server certificate issued by StartSSL for which the private key leaked (for example through the OpenSSL Heartbleed bug), can not only be used to attack the affected server/service but also gives full access to the StartCom account which originally requested the certificate.
An attacker could for example revoke the customer’s original client certificate before the customer could revoke the leaked server certificate, and therefore buy more time to use the leaked certificate. Or as an denial of service, an attacker could just revoke the certificates of other servers associated with the account. Another attack could be spending the customers money using his StartSSL registered credit card for StartSSL services and the customer had the trouble proving it wasn’t him.
If I’m not totally mistaken here, this should be an even bigger reason to fix your affected systems and revoke your potentially leaked certificates. Also I would like to see StartCom working on disabling this as I honestly don’t see any argument for granting each server certificate full account control access.
-
