SSLv3 Cipher Extension/Support?

[stephen....@gmail.com]

I'm having some trouble reading data from a particular host over SSL that has a SSLv3 Cipher of DHE-RSA-AES256-GCM-SHA384. From what I can tell the first parts of this cipher are supported up until GCM-SHA384. This is based on reading: through http://golang.org/src/pkg/crypto/tls/cipher_suites.go

Is there any way to extend/support the TLS client for this cipher? I can always bypass SSL certificate validation, but that's not my goal, I'd like to be able to make requests using SSL if possible.

Thank you!

[StalkR]

Hi Stephen,

Is your error x509: cannot verify signature: algorithm unimplemented?

As Hotei suggested, try importing crypto/sha512 for the side effect that it will register sha512 and sha384 hash algorithms.

For instance in your main package imports, add:

import (

   ...

    _ "crypto/sha512"

)

otherwise what's the detailed error?

On Thu, Apr 10, 2014 at 9:03 PM, Hotei <hote...@gmail.com> wrote:

From crypto pkg - note SHA384 is found in SHA512, not as a separate pkg

const (
        MD4       Hash = 1 + iota // import code.google.com/p/go.crypto/md4
        MD5                       // import crypto/md5
        SHA1                      // import crypto/sha1
        SHA224                    // import crypto/sha256
        SHA256                    // import crypto/sha256
        SHA384                    // import crypto/sha512
        SHA512                    // import crypto/sha512
        MD5SHA1                   // no implementation; MD5+SHA1 used for TLS RSA
        RIPEMD160                 // import code.google.com/p/go.crypto/ripemd160

)

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[stephen....@gmail.com]

The error I get, and this might be a red herring is:

 

 "remote error: handshake failure"

Here's an example program that fails:

package main

import (

"log"

"net/http"

)

func main() {

c := new(http.Client)

r, err := c.Get("https://developers.databox.com")

if err != nil {

log.Print(err)

}

log.Print(r)

}

Output is:

$ go run ssl-test.go

2014/04/10 12:47:10 Get https://developers.databox.com: remote error: handshake failure

2014/04/10 12:47:10 <nil>

Anyone able to offer some insight?

[StalkR]

So yes it looks like the server is pretty picky on the ciphers and unfortunately doesn't match with any of the ones supported in Go.

From a basic openssl test, it appears the server only supports:

DHE-RSA-AES256-GCM-SHA384

DHE-RSA-AES256-SHA256

DHE-RSA-AES256-SHA

DHE-RSA-CAMELLIA256-SHA

DHE-RSA-AES128-GCM-SHA256

DHE-RSA-AES128-SHA256

DHE-RSA-AES128-SHA

DHE-RSA-SEED-SHA

As you've read in cipher_suites.go above, Go currently only supports ECDHE (not DHE) and does not support SHA384.

You can surely extend Go's support by modifying the library locally.

And maybe agl@ has some future plans to improve the supported ciphersuites?

[StalkR]

I filed a feature request for DHE support https://code.google.com/p/go/issues/detail?id=7758

[Raffaele Sena]

You can use my "extended" tls package from here:

https://github.com/raff/tls-ext

It's a copy of go tls that allows adding new cipher suites, that I need to add support for tls-psk. It turns out that I had to export too many things to allow the appropriate processing of key exchanges and stuff so I am a little leery to propose merging it back in (a better solution would be to split the tls package into, for example, "tls" for the currently exported functionalities and "tls-internal" for stuff related to adding cihper suites and what not.

Anyway, back to your problem, check this to see how to add the new ciphersuites using "tls.RegisterCipherSuites":

https://github.com/raff/tls-psk/blob/master/psk.go

-- Raffaele

[Jeff Hodges]

One thing to note is that GCM is not defined for SSLv3. It's first appearance is in TLS 1.2 with RFC 5288. <http://tools.ietf.org/html/rfc5288>

[fr...@runscope.com]

Another similar issue seems to be cropping up with the signing algorithm for an intermediate CA:

Get https://api.moip.com.br/: x509: certificate signed by unknown authority (possibly because of "x509: cannot verify signature: algorithm unimplemented" while trying to verify candidate authority certificate "COMODO RSA Certification Authority")

Seems to be signed with "SHA-384 with RSA Encryption"

It looks like I'm seeing a lot more of these crop up since everyone has updated/reissued certs following the Heartbleed announcement.

[StalkR]

Hi Frank,

This is a different issue (cert signature verification, not tls cipher).

Solution: import crypto/sha512 for the side effect that it will register sha384/512 algorithms.

For instance in your main package imports, add:

import (

   ...

    _ "crypto/sha512"

)

Also does it still error? it works for me and I see sha256 as a signature algorithm, maybe they just changed.

$ echo | openssl s_client -connect api.moip.com.br:443 -servername api.moip.com.br 2>&1 | openssl x509 -text | grep -m 1 'Signature Algorithm'

    Signature Algorithm: sha256WithRSAEncryption

[fr...@runscope.com]

Yep, that fixes that issue.  Thanks for the quick reply!

And yeah, the original still errors for me.  I think the error is produced from verifying the 3rd certificate in the chain.  "COMODO RSA Certification Authority"

---

Certificate chain

 0 s:/serialNumber=08718431000108/1.3.6.1.4.1.311.60.2.1.3=BR/1.3.6.1.4.1.311.60.2.1.2=Sao Paulo/businessCategory=Private Organization/C=BR/postalCode=01452000/ST=Sao Paulo/L=Sao Paulo/street=Avenida Brigadeiro Faria Lima , 2927/O=Moip Pagamentos S.A./OU=MOIP/OU=SSL Blindado EV/CN=api.moip.com.br

   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Extended Validation Secure Server CA

 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Extended Validation Secure Server CA

   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority

 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority

   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

---

[StalkR]

Oh, and I just saw https://codereview.appspot.com/87670045 crypto/sha512 is now supported by default so you likely won't need this in the future release.