Honzab wrote:
All right, everything is working now. We found a mistake in our code -
setting for ECC suites were inside of #ifdef NSS_ENABLE_ECC which was
not defined. We define this symbol now and disable all ECC suites for
all prototypes of socket we use (client and server too).
I used Wireshark to watch the traffic and found a very strange behavior
(the reason of the connection failure):
- ClientHello packet contains (among others) suite 0xC014
(TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA).
- ServerHello packet contains this suite as negotiated to be used for
the ssl session
- Client answers with fatal alert: Handshake Failure (40)
I did not investigate the reason deeply, but it might be potentialy a
bug in NSS 3.11 (?). Code in mozilla\security\nss\lib\ssl\ssl3con.c
line 4488 doesn't consider the suite as suitable for the session and
breaks the negotiation with fatal alert. This is strange, because the
client socket sent this suite in the list of suits as available for the
session.
Does this error also occur with NSS 3.11.3 ? Many ECC related bugs were
fixed after the original NSS 3.11 . If you aren't using the latest,
please upgrade.
If the problem still occurs, you might need to file a bug. You'll need
to provide all the information to reproduce the problem, ideally your
server cert and private key in a PKCS#12 file if you can, and
instructions on how to reproduce with the NSS tools tstclnt and selfserv.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
