tls.connect Error: self signed certificate when connect to imap.gmail.com:933

[CoNETProject]

• Version: v12.0.0 ~ v12.4.0 (Old ~ v11.15.0 have no same issue )
• Platform: MacOS, Debian, Windows
• Subsystem: no
• Module (and version) (if relevant): tls.connect(options[, callback])

Error: self signed certificate

When?
looks happened connect to imap.gmail.com:933 only.

imap.mail.me.com have no same issue.

//	This only happen at v12.0.0 ~ v12.4.0 (Old version ~ v11.15.0 have no same issue )

const socket = tls.connect (993, 'imap.gmail.com', () => {
	...
)
socket.on('error', err => {
	// Will ERROR!
	// Error: self signed certificate
	...
})

//	Apple mail have no same problem
const socket = tls.connect (993, 'imap.mail.me.com', () => {
	...
)
socket.on('error', err => {
	...
})

I checked tls connect with openssl command to imap.gmail.com at same OS, looks Good. It have not Man-in-the-middle attack OS. The code have no problem when I back NodeJS to v11.

[addaleax]

@nodejs/crypto

[bnoordhuis]

The issue is that Node.js (no longer?) sends a SNI record by default. You can work around it like this:

const options = {
  port: 993,
  host: 'imap.gmail.com',
  servername: 'imap.gmail.com',  // SNI
};
tls.connect(options, () => { /* ... */ });

It might have been caused by an openssl upgrade because I can reproduce with out/Release/openssl-cli, that also won't validate unless you pass -servername imap.gmail.com.

(GMail helpfully sends back a certificate with Issuer: OU = "No SNI provided; please fix your client.", CN = invalid2.invalid ^^)

[CoNETProject]

Thank you.
Looks have no problem now via use both host and servername.

[silverwind]

I can reproduce with out/Release/openssl-cli

Sending SNI on the openssl CLI was always opt-in via -servername, so that's probably not related.

[sam-github]

This might be a bug. 11.x and 12.x have the same OpenSSL version, but different behaviour, so it looks like something changed in node, not in openssl:

w/core % cat imap.gmail.js
console.log(process.versions.openssl);
require('tls').connect(993, 'imap.gmail.com', function() {
  console.log('CONNECT');
  this.end();
});
w/core % nvm run 11 imap.gmail.js
Running node v11.15.0 (npm v6.7.0)
1.1.1b
CONNECT
w/core % nvm run 12 imap.gmail.js
Running node v12.4.0 (npm v6.9.0)
1.1.1b
events.js:177
      throw er; // Unhandled 'error' event
      ^

Error: self signed certificate
    at TLSSocket.onConnectSecure (_tls_wrap.js:1317:34)
    at TLSSocket.emit (events.js:200:13)
    at TLSSocket._finishInit (_tls_wrap.js:792:8)
    at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:606:12)
Emitted 'error' event at:
    at emitErrorNT (internal/streams/destroy.js:91:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
    at processTicksAndRejections (internal/process/task_queues.js:84:9) {
  code: 'DEPTH_ZERO_SELF_SIGNED_CERT'
}

[sam-github]

I'm bisecting, maybe I can pinpoint a specific change.

[bnoordhuis]

Sending SNI on the openssl CLI was always opt-in via -servername, so that's probably not related.

The reason I mention it is that the stock openssl s_client on my system works without -servername.

[silverwind]

openssl s_client on my system works without -servername

We're offtopic but it's because it was changed in 1.1.1 as per this changelog entry:

s_client will now send the Server Name Indication (SNI) extension by
default unless the new "-noservername" option is used. The server name is
based on the host provided to the "-connect" option unless overridden by
using "-servername".

[sam-github]

bisect pointed to 42dbaed, my commit to add TLS1.3 support, and indeed it works with TLS1.2:

core/lts (master $% u=) % ./out/Release/node --tls-max-v1.3 ../imap.gmail.js
1.1.1b
events.js:177
      throw er; // Unhandled 'error' event
      ^

Error: self signed certificate
    at TLSSocket.onConnectSecure (_tls_wrap.js:1317:34)
    at TLSSocket.emit (events.js:200:13)
    at TLSSocket._finishInit (_tls_wrap.js:792:8)
    at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:606:12)
Emitted 'error' event at:
    at emitErrorNT (internal/streams/destroy.js:91:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
    at processTicksAndRejections (internal/process/task_queues.js:74:11) {
  code: 'DEPTH_ZERO_SELF_SIGNED_CERT'
}
core/lts (master $% u=) % ./out/Release/node --tls-max-v1.2 ../imap.gmail.js 
1.1.1b
CONNECT

However, running with --trace-tls I see something strange: SNI is not sent for TLS1.2 or TLS1.3 (by default), but only for TLS1.3 is the server returning the bogus self-signed cert with Subject = Issuer = "No SNI provided; please fix your client.", CN = invalid2.invalid. If I add SNI, it does fix the TLS1.3 connect, but why? Is the SNI extension required for TLS1.3? Well, no, but it is by google's servers: openssl/openssl#5362 (comment)

So, this is confirmed as a gmail bug.

Possibly, tls.connect() should default servername: to host: (in the case that host is a name and not an IP address) as http.request() does, but that would be a breaking change.

Thoughts?

More discussion: https://mta.openssl.org/pipermail/openssl-project/2018-April/000623.html

[bnoordhuis]

I suppose GMail is technically in the right because the spec says that a server MAY require SNI and imap.gmail.com does....

...although it's "interesting" that it doesn't actually care what you set the servername to: it happily accepts -servername panopticon.bigbro. Can I suggest we add a special case for imap.gmail.com and send that servername? ^^

We could turn on SNI by default although that leaks the servername because the SNI payload is unencrypted (and it'll be a while before ESNI is a thing.)

[silverwind]

I guess we have to default to sending a SNI (and mimic what browsers do). It is indeed a data leak, but I guess more services will work with it present than without.

BTW, I don't expect ESNI in the current draft form to get any widespread adoption because of it's complexity.

[sam-github]

@silverwind We already mimic what browsers do by defaulting to sending SNI for https (see Agent.prototype.addRequest), so it is only direct use of tls that doesn't set servername. I'll PR a default use of servername to tls.connect (unless someone else beats me to it).