crypto/tls: Connection reset with TLS server (only on 1.1 / tip) and firefox

[gopherbot]

by viriketo:

I see the problem with my program 'filegive' (http://viric.name/cgi-bin/filegive/),
which spawns a TLS listener for http connections.

With go 1.0.3, all works fine. With 1.1rc1, 1.1rc3, tip 30c566874b83, firefox reports
"Connection Reset" after accepting the self-signed certificate, connecting to
the 'filegive' https server.

Steps to reproduce:
# Generate 2048bit rsa certificates
$ filegive -g
# Serve a file
$ filegive ssh.go
Fingerprint SHA1: 6a 9f ee f9 ce 96 96 ec 79 f8 5f d8 28 38 96 b7 23 4e 44 3d
https://192.168.1.34:49437/jxrbqicl/ssh.go

Going to the URL with firefox, and accepting the 'untrusted' certificate, ends up in
Connetion Reset. Using curl and opera, it works.

Building 'filegive' with go 1.0.3 makes it work perfect.

Extra tests I've done changing the code:
1) Setting the rsa key length to 1024bit produces the same outcome
2) Setting CipherSuite to nil (allowing the slow des3), produces the same outcome.

[gopherbot]

Comment 1 by viriketo:

Just for more details:
I use linux/amd64, and I'm testing with firefox 20.0.

[gopherbot]

Comment 2 by viriketo:

I could reproduce the same in windows/x86

[gopherbot]

Comment 3 by viriketo:

Can anyone reproduce this? Is this a firefox problem?

[dominikh]

Comment 4:

I can reproduce this with Firefox 17 on Linux.

[dominikh]

Comment 5:

Imho this is a bug in filegive, not Go. In your NewHttpsListener, where you construct
your own TLS listener, you're not setting the NextProtos field of the tls.Config struct.
If you check how http.ListenAndServeTLS works, you'll see that you want to set this to
[]string{"http/1.1"} -- And if you do that, it indeed works.

[bradfitz]

Comment 6:

Should a NPN of []string{"http/1.1"} be required? I thought that was implicit. Adam?

[agl]

Comment 7:

No, setting NextProtos shouldn't be needed. HTTP/1.1 is the default. I'll see if I can
install Firefox and check this out.

[agl]

Comment 8:

I can't reproduce (although I have Firefox 21 here).
I'm just running this code:
package main
import (
    "net/http"
)
func main() {
    if err := http.ListenAndServeTLS(":8080", "cert.pem", "key.pem", nil); err != nil {
        panic(err)
    }
}
Where the key pair is from:
% openssl genrsa 1024 > key.pem
% openssl req -new -x509 -key key.pem -out cert.pem -days 1095

[dominikh]

Comment 9:

http.ListenAndServeTLS will work just fine, because it sets the TLS's listener
NextProtos field explicitly.
What the original code does is manually construct a TLS listener. I reduced the
original, rather long program to this single file that demonstrates the issue:
http://play.golang.org/p/qLahG6ZWn7

[agl]

Comment 10:

Thanks for that.
This is a little bit of a Go issue, but mostly a Firefox issue. Go shouldn't be sending
an empty NPN extension when NextProtos is nil, but that's not a big deal.
The real problem is that, in the event of a mismatch, Firefox is defaulting to sending
an NextProtocol of spdy/3, but actually talking HTTP/1.1! I've made a note and will
chase up the FF folks on Monday. I'll also fix the Go issue and that should solve it too.

Labels changed: added priority-soon, go1.1.1, packagebug, removed priority-triage.

Owner changed to @agl.

Status changed to Accepted.

[gopherbot]

Comment 11 by viriketo:

Thank you all!
The current fixing path looks great. I added the NextProtos to my code, too.
It'd be nice to link here to the firefox issue, if created.

[agl]

Comment 12:

This issue was closed by revision 8590e1b.

Status changed to Fixed.

[agl]

Comment 13:

I emailed the right person at Mozilla directly so I don't have a bug link. Hopefully it
gets sorted out soon.

[ianlancetaylor]

Comment 14:

Labels changed: removed go1.1.1.