With node, when making a tls connection, the authorized status and authorizationError includes the result of the certificate idenity check, see https://github.com/nodejs/node/blob/master/lib/_tls_wrap.js#L1091.
With starttls, the identicy check is done after, https://github.com/mattcg/starttls/blob/master/lib/starttls.js#L96, and is done unconditionally, so that if a cert is not trusted, but does pass the tls.checkServerIdentity() check, someone using your example code will consider the connection valid, even though .authorized may be false.
From the README:
starttls(options, function(err) {
if (err) {
does not appear secure to me under these conditions.
Also,
starttls(socket, function(err) {
if (!tls.checkServerIdentity(host, this.cleartext.getPeerCertificate())) {
// Hostname mismatch!
// Report error and end connection...
}
});
this appears to completely ignore the error object, so a naive use of it will accept invalid certs, that purport to be for the hostname the user is trying to make a secure connection to but have not been validly issued by a trusted CA.
With node, when making a tls connection, the authorized status and authorizationError includes the result of the certificate idenity check, see https://github.com/nodejs/node/blob/master/lib/_tls_wrap.js#L1091.
With starttls, the identicy check is done after, https://github.com/mattcg/starttls/blob/master/lib/starttls.js#L96, and is done unconditionally, so that if a cert is not trusted, but does pass the tls.checkServerIdentity() check, someone using your example code will consider the connection valid, even though .authorized may be false.
From the README:
does not appear secure to me under these conditions.
Also,
this appears to completely ignore the error object, so a naive use of it will accept invalid certs, that purport to be for the hostname the user is trying to make a secure connection to but have not been validly issued by a trusted CA.