I try to only use 256bit cipher suites only with following setup:
const https = require('https');
const fs = require('fs');
const constants = require('constants');
const serverKey = 'server.key';
const serverCrt = 'server.crt';
httpsOptions = {
key: fs.readFileSync(serverKey),
cert: fs.readFileSync(serverCrt),
secureOptions: constants.SSL_OP_NO_TLSv1 | constants.SSL_OP_NO_TLSv1_1,
ciphers: [
'ECDHE-ECDSA-AES256-GCM-SHA384',
'ECDHE-RSA-AES256-GCM-SHA384',
"HIGH",
"!aNULL",
"!eNULL",
"!EXPORT",
"!DES",
"!RC4",
"!MD5",
"!PSK",
"!SRP",
"!CAMELLIA"
].join(':')
};
https.createServer(httpsOptions, (req, res) => {
res.writeHead(200);
res.end('hello world\n');
}).listen(8000);
However sslscan and ssllabs.com (my blog is using the same httpsOptions) testing show I still have
128bit ciphers
NON-GCM ciphers
Following is out put from sslscan:
[23:13:03]JS#JS-Mac-mini ~> sslscan localhost:8000
Version: 1.11.8
OpenSSL 1.0.2k 26 Jan 2017
OpenSSL version does not support SSLv2
SSLv2 ciphers will not be detected
Testing SSL server localhost on port 8000
TLS Fallback SCSV:
Server supports TLS Fallback SCSV
TLS renegotiation:
Session renegotiation not supported
TLS Compression:
Compression disabled
Heartbleed:
TLS 1.2 not vulnerable to heartbleed
TLS 1.1 not vulnerable to heartbleed
TLS 1.0 not vulnerable to heartbleed
Supported Server Cipher(s):
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA384 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve P-256 DHE 256
Accepted TLSv1.2 256 bits AES256-GCM-SHA384
Accepted TLSv1.2 256 bits AES256-SHA256
Accepted TLSv1.2 256 bits AES256-SHA
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve P-256 DHE 256
Accepted TLSv1.2 128 bits AES128-GCM-SHA256
Accepted TLSv1.2 128 bits AES128-SHA256
Accepted TLSv1.2 128 bits AES128-SHA
SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength: 2048
Subject: localhost
Issuer: localhost
Not valid before: Jun 13 19:06:29 2016 GMT
Not valid after: Jun 13 19:06:29 2017 GMT
I expect to see only the following ciphers:
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve P-256 DHE 256
You're including HIGH in your SSL cipher configuration, which includes all the ciphers that OpenSSL considers high strength (128bit or above), and then you're excluding some specific other groups of ciphers. Remove HIGH and you'll just get the ciphers you want.
You can see what's in each group in OpenSSL from the command line with $ openssl ciphers -v HIGH
Alternatively you might just be able to specify the ciphers you want, and remove everything else.
add !AES128 to disable these 128bit ciphers.
sample:
ciphers: "ECDHE-RSA-AES256-GCM-SHA384:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!SRP:!CAMELLIA:HIGH:!AES128"
then supported ciphers will be:
Supported Server Cipher(s):
Accepted TLSv1 256 bits ECDHE-RSA-AES256-SHA
Accepted TLSv1 256 bits AES256-SHA
Accepted TLS11 256 bits ECDHE-RSA-AES256-SHA
Accepted TLS11 256 bits AES256-SHA
Accepted TLS12 256 bits ECDHE-RSA-AES256-GCM-SHA384
Accepted TLS12 256 bits ECDHE-RSA-AES256-SHA384
Accepted TLS12 256 bits ECDHE-RSA-AES256-SHA
Accepted TLS12 256 bits AES256-GCM-SHA384
Accepted TLS12 256 bits AES256-SHA256
Accepted TLS12 256 bits AES256-SHA
Related
i've created my own CA and intermediate CA with openssl.
On my Zyxel AP i've created an csr.
I signed the csr through my intermediate CA and imported the server
cert to my zyxel AP.
I've also uploaded the fullchain root CA (CA and Intermediate) to my zyxel AP.
I'm using ubuntu so i've installed fullchain CA in my cerstore (/usr/local/share/ca-certificates | update update-ca-certificates)
I also imported the fullchain CA in my Browser Cert Store (tested with firefox, brave)....
But when i now call up the webgui from my AP i get the follwing message:
SSL_ERROR_BAD_CERT_DOMAIN
This happens for all browsers.
When i check with curl or openssl, everything looks good:
curl -vvI https://zyxel.home.arpa
ALPN: offers h2
* ALPN: offers http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256
.
.
.
SSL certificate verify ok.
openssl s_client -CAfile ca-chain-bundle.cert.pem https://zyxel.home.arpa
New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
What can i try to fix this browser issue?
Edit 1:
without CAfile:
openssl s_client -connect zyxel.home.arpa:443
.
.
verify error:num=20:unable to get local issuer certificate
.
verify error:num=21:unable to verify the first certificate
.
Edit 2:
# President James K. Polk, here are the output of the server crt:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 37:5b:25:e6:31:1b:7e:f7:63:14:30:e1:b6:ca:d2:11:a2:83:44:1c
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = DE, ST = Home, O = Home Inc., CN = Home Intermediate-CA, emailAddress = admin#home.sh
Validity
Not Before: Nov 22 20:20:47 2022 GMT
Not After : Nov 22 20:20:47 2023 GMT
Subject: CN = zyxel.home.arpa, C = DE, ST = Home, L = Home, O = Home Inc, OU = IT
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:aa:be:cf:97:ad:fd:da:1a:9b:c4:af:9a:07:ac:
b7:08:bb:e3:eb:b8:d0:dc:fc:34:bf:8c:c8:5b:3f:
37:a7:20:7d:7e:eb:c9:e1:ce:c6:a8:84:2a:a3:35:
74:83:c9:62:94:ad:92:5b:c5:54:99:9e:14:c9:2b:
73:44:75:06:de:d4:dc:13:a6:0c:8c:b6:d9:84:e2:
1e:51:f8:2f:83:3c:62:95:ca:32:39:07:2b:81:41:
f9:88:08:95:fb:f9:c2:10:f0:de:25:b6:e2:83:f0:
f2:86:41:7d:5d:09:91:3b:04:b8:5f:74:b7:f5:2e:
e8:fa:9b:f5:17:a7:ef:d1:45:ed:05:8e:f3:8e:c3:
a1:96:42:9d:dd:ef:2f:03:81:97:b9:c5:df:9c:41:
3b:b6:9d:7b:09:a0:bf:ad:e8:6a:e2:05:ef:2b:fc:
67:4d:5a:dd:a4:ba:7b:58:a8:65:53:08:06:60:00:
08:85:12:34:31:9b:93:27:d2:35:75:00:f0:01:f5:
58:7f:1a:e5:1f:e5:08:8a:14:ca:c4:17:4d:90:ec:
30:7a:38:3e:ad:90:db:08:46:35:c4:6e:a7:8e:81:
77:eb:15:47:50:7e:d1:71:d5:09:38:64:c3:fa:08:
2a:31:a0:bd:87:0b:70:27:b3:42:fe:20:de:b1:be:
87:a9
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
OpenSSL Generated Server Certificate
X509v3 Subject Key Identifier:
F5:D6:9B:95:CA:2C:8E:41:92:5F:3E:3E:9C:D5:31:CE:6A:D0:F8:95
X509v3 Authority Key Identifier:
keyid:25:0C:ED:3A:E1:A0:B9:86:A0:FB:43:9F:20:F0:F4:C0:5E:85:C4:D7
DirName:/C=DE/ST=Home/L=Home/O=Home Inc./CN=Home Root-CA/emailAddress=admin#home.sh
serial:01
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
and here's the output ofthe generated csr on the zyxel AP:
Certificate Request:
Data:
Version: 1 (0x0)
Subject: CN = zyxel.home.arpa, C = DE, ST = Home, L = Home, O = Home Inc, OU = IT
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:aa:be:cf:97:ad:fd:da:1a:9b:c4:af:9a:07:ac:
b7:08:bb:e3:eb:b8:d0:dc:fc:34:bf:8c:c8:5b:3f:
37:a7:20:7d:7e:eb:c9:e1:ce:c6:a8:84:2a:a3:35:
74:83:c9:62:94:ad:92:5b:c5:54:99:9e:14:c9:2b:
73:44:75:06:de:d4:dc:13:a6:0c:8c:b6:d9:84:e2:
1e:51:f8:2f:83:3c:62:95:ca:32:39:07:2b:81:41:
f9:88:08:95:fb:f9:c2:10:f0:de:25:b6:e2:83:f0:
f2:86:41:7d:5d:09:91:3b:04:b8:5f:74:b7:f5:2e:
e8:fa:9b:f5:17:a7:ef:d1:45:ed:05:8e:f3:8e:c3:
a1:96:42:9d:dd:ef:2f:03:81:97:b9:c5:df:9c:41:
3b:b6:9d:7b:09:a0:bf:ad:e8:6a:e2:05:ef:2b:fc:
67:4d:5a:dd:a4:ba:7b:58:a8:65:53:08:06:60:00:
08:85:12:34:31:9b:93:27:d2:35:75:00:f0:01:f5:
58:7f:1a:e5:1f:e5:08:8a:14:ca:c4:17:4d:90:ec:
30:7a:38:3e:ad:90:db:08:46:35:c4:6e:a7:8e:81:
77:eb:15:47:50:7e:d1:71:d5:09:38:64:c3:fa:08:
2a:31:a0:bd:87:0b:70:27:b3:42:fe:20:de:b1:be:
87:a9
Exponent: 65537 (0x10001)
Attributes:
Netscape Comment :OpenSSL Generated Certificate
Requested Extensions:
X509v3 Subject Key Identifier:
F5:D6:9B:95:CA:2C:8E:41:92:5F:3E:3E:9C:D5:31:CE:6A:D0:F8:95
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Data Encipherment, Certificate Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Server Authentication
X509v3 Subject Alternative Name:
othername: UPN::zyxel.home.arpa, DNS:zyxel.home.arpa
Signature Algorithm: sha512WithRSAEncryption
Signature Value:
1b:04:05:e6:02:89:4d:1d:67:a4:bb:15:06:20:93:58:c3:2b:
72:3c:e0:39:cd:f0:ea:6e:3a:db:33:02:3e:fa:ca:67:ec:e4:
58:a5:cf:ad:c0:51:b1:bb:0d:22:3f:a5:fc:ac:d1:e9:90:d6:
71:71:5d:dc:56:f1:14:21:cb:a3:53:be:0a:32:43:8f:8a:74:
55:08:e3:1d:44:7d:72:f3:94:7f:1a:99:71:b7:97:be:a6:ff:
a8:cf:95:f5:3b:c3:c6:6c:e3:ef:d9:39:8d:03:17:2e:15:2c:
92:ee:00:88:5f:23:21:a4:ac:27:c6:66:00:a5:5d:89:8d:f3:
87:43:34:35:16:e4:bd:72:38:ba:2c:27:f4:c9:08:22:aa:86:
21:6c:98:9f:4b:2b:7e:5e:6a:aa:5c:19:80:29:32:6d:4f:78:
1d:db:5b:1d:a1:bc:31:86:e9:65:af:ee:30:35:12:ce:d4:18:
b1:06:57:e3:da:f6:63:b0:48:53:64:0a:4b:ca:2a:20:d6:5d:
90:1a:bf:af:bb:d3:18:e8:5e:42:2f:3f:c8:96:20:63:66:9e:
2e:b1:2a:fa:82:f6:ba:d0:d3:7f:e7:a5:5d:f5:3a:fb:a9:b0:
54:a5:0a:14:48:8a:37:1e:e8:32:6c:73:7d:4c:af:dc:21:bc:
24:60:9e:2c
Solution:
i forgot to add the Subject Alt Name part into my openssl.cnf (thanks for the hint President James K. Polk):
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = #alt_names
[alt_names]
IP.1 = IP
DNS.1 = DNS NAME
I have a barebone simple example that works locally but not in Azure. My original question was a bit specific to an cors-error, that i have now worked around, and therefor edited away that part. But i still cant manage to make WS work on azure. And i need help.;
var server = http.Server(app);
const wss = new WebSocket.Server({server});
server.listen(8070, () => {
console.log("Listening on " + port)
});
wss.on('connection', (socket) => {
console.log('a user connected');
socket.on('message', (msg) => {
console.log(msg)
socket.send(JSON.stringify({hey:'you'}))
})
});
client connection-string:
SOCKET_ENDPOINT = 'wss://******.azurewebsites.net/';
I've turned on websockets in my app-configuration.
EDIT:
So i have now turned every stone. Even switched library from socket.io to ws. Same problem. I came a little further i think when trying different things, now i get following error "Firefox can’t establish a connection to the server at wss://*******.azurewebsites.net:8070/."
Edit2:
The http-upgrade is fine
Here's the error
Edit 3: Curl command:
* TCP_NODELAY set
* Connected to *******.azurewebsites.net (20.40.202.6) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=*.azurewebsites.net
* start date: Sep 28 19:00:01 2020 GMT
* expire date: Sep 28 19:00:01 2021 GMT
* subjectAltName: host "********.azurewebsites.net" matched cert's "*.azurewebsites.net"
* issuer: C=US; O=Microsoft Corporation; CN=Microsoft RSA TLS CA 01
* SSL certificate verify ok.
> GET /socket.io/?EIO=4 HTTP/1.1
> Host: *********.azurewebsites.net
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< Server: Kestrel
< WWW-Authenticate: Bearer realm="********.azurewebsites.net" authorization_uri="https://login.windows.net/<tenant>/oauth2/authorize" resource_id="<resource>"
< Date: Tue, 22 Jun 2021 05:56:15 GMT
< Content-Length: 0
<
* Connection #0 to host *******.azurewebsites.net left intact
I am guessing that you host your app in Azure AppService?
Make sure you have websocket option turned on in platform:
AppService resource -> Settings -> General settings tab -> Platform settings section
I'm having trouble getting an WSDL file via cURL. I think it has to be related to the cURL version. The command is working in a Docker image based on Debian 9, cURL version:
# curl --version
curl 7.52.1 (x86_64-pc-linux-gnu) libcurl/7.52.1 OpenSSL/1.0.2l zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
However, the baseimage was updated to Debian 10 and there the command is not running. cURL Version:
# curl --version
curl 7.64.0 (x86_64-pc-linux-gnu) libcurl/7.64.0 OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3
Release-Date: 2019-02-06
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
I can download the WSDL with wget or with an browser but I need cURL for this command. I found this answer and I tried the cURL command copied from Chromium but get the same result...
The command:
# curl -vvv -k --header "Authorization: Basic <B64Encoded>" https://IP/service.asmx?WSDL -o /dev/null
outputs on debian 9 (cURL 7.52.1):
* Trying IP...
* TCP_NODELAY set
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to IP (IP) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [81 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [753 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=WMSvc-VS47558B
* start date: Sep 5 11:51:31 2016 GMT
* expire date: Sep 3 11:51:31 2026 GMT
* issuer: CN=WMSvc-VS47558B
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
} [5 bytes data]
> GET /service.asmx?WSDL HTTP/1.1
> Host: IP
> User-Agent: curl/7.52.1
> Accept: */*
> Authorization: Basic RUNTOnA5NDEtRUNTMjAyMQ==
>
{ [5 bytes data]
< HTTP/1.1 200 OK
< Cache-Control: private, max-age=0
< Content-Type: text/xml; charset=utf-8
< Server: Microsoft-IIS/8.5
< X-AspNet-Version: 4.0.30319
< X-Powered-By: ASP.NET
< Date: Fri, 12 Mar 2021 21:41:16 GMT
< Content-Length: 243498
<
{ [16151 bytes data]
* Curl_http_done: called premature == 0
100 237k 100 237k 0 0 2083k 0 --:--:-- --:--:-- --:--:-- 2104k
* Connection #0 to host IP left intact
* List item
and on Debian 10 (cURL 7.64.0)
* Expire in 0 ms for 6 (transfer 0x5555fcd9df50)
* Trying IP...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5555fcd9df50)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to IP (IP) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to IP:443
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to IP:443
Does it something have to do with the ca-certs?
On Debian 10 this package is installed: ca-certificates/now 20200601~deb10u1 all [installed,local]
On Debian 9 ca-certs is not installed
Forcing a TLS Version below 1.3 gives the same result. The remote server is a Windows Server 2012, I think they are using just outdated ciphers or something. But how can I proove that and is there a workaround? In the cURL changelogs I didn't find a change like 'drop support for....' or something.
I want to disable tls 1.3 and use specific cipher suites when sending request using npm request package inside my electron app.
I found when I run it by "npm start" which actaully is "electron ."(my function is in main process), it sents tls client handshake message with an extra field "extension_supported_versions" saying supporting tls1.3. And carrying 46 cypher suites.
If it is ran by "node test.js", then only 18 cipher suites is sent out.
Reuqest package version is 2.88.0 in both cases. I wonder why such difference exists. Seems electron did something to impact the cipher suite selection process of request package.
"ELectron ."
Frame 80754: 305 bytes on wire (2440 bits), 305 bytes captured (2440 bits) on interface 0
Ethernet II, Src: IntelCor_18:36:61 (78:0c:b8:18:36:61), Dst: Tp-LinkT_9d:52:bc (bc:46:99:9d:52:bc)
Internet Protocol Version 4, Src: 192.168.1.101, Dst: 27.148.140.18
Transmission Control Protocol, Src Port: 53505, Dst Port: 443, Seq: 1, Ack: 1, Len: 251
Transport Layer Security
TLSv1.3 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 246
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 242
Version: TLS 1.2 (0x0303)
Random: b5e74f961551b2deda4486f6d138b97c0d12419b756cda10…
Session ID Length: 32
Session ID: 4e7b9be07d3d89c6e9d9ffb7bbb6fbf971b5d2912f9e8584…
Cipher Suites Length: 36
Cipher Suites (18 suites)
Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 133
Extension: server_name (len=17)
Type: server_name (0)
Length: 17
Server Name Indication extension
Server Name list length: 15
Server Name Type: host_name (0)
Server Name length: 12
Server Name: api.nike.com
Extension: extended_master_secret (len=0)
Type: extended_master_secret (23)
Length: 0
Extension: renegotiation_info (len=1)
Type: renegotiation_info (65281)
Length: 1
Renegotiation Info extension
Extension: supported_groups (len=8)
Type: supported_groups (10)
Length: 8
Supported Groups List Length: 6
Supported Groups (3 groups)
Extension: ec_point_formats (len=2)
Type: ec_point_formats (11)
Length: 2
EC point formats Length: 1
Elliptic curves point formats (1)
Extension: session_ticket (len=0)
Type: session_ticket (35)
Length: 0
Data (0 bytes)
Extension: signature_algorithms (len=20)
Type: signature_algorithms (13)
Length: 20
Signature Hash Algorithms Length: 18
Signature Hash Algorithms (9 algorithms)
Extension: key_share (len=38)
Type: key_share (51)
Length: 38
Key Share extension
Extension: psk_key_exchange_modes (len=2)
Type: psk_key_exchange_modes (45)
Length: 2
PSK Key Exchange Modes Length: 1
PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1)
Extension: supported_versions (len=5)
Type: supported_versions (43)
Length: 5
Supported Versions length: 4
Supported Version: TLS 1.3 (0x0304)
Supported Version: TLS 1.2 (0x0303)
"Node test.js"
Frame 80283: 287 bytes on wire (2296 bits), 287 bytes captured (2296 bits) on interface 0
Ethernet II, Src: IntelCor_18:36:61 (78:0c:b8:18:36:61), Dst: Tp-LinkT_9d:52:bc (bc:46:99:9d:52:bc)
Internet Protocol Version 4, Src: 192.168.1.101, Dst: 27.155.111.241
Transmission Control Protocol, Src Port: 53496, Dst Port: 443, Seq: 1, Ack: 1, Len: 233
Transport Layer Security
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 228
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 224
Version: TLS 1.2 (0x0303)
Random: 0193f22cc60e33bca73d481c887826386fda6bd2cfb12e48…
Session ID Length: 0
Cipher Suites Length: 92
Cipher Suites (46 suites)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
Cipher Suite: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xccaa)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 (0xc0af)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CCM (0xc0ad)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CCM_8 (0xc0a3)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CCM (0xc09f)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (0xc0ae)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CCM (0xc0ac)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CCM_8 (0xc0a2)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CCM (0xc09e)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_256_CCM_8 (0xc0a1)
Cipher Suite: TLS_RSA_WITH_AES_256_CCM (0xc09d)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_128_CCM_8 (0xc0a0)
Cipher Suite: TLS_RSA_WITH_AES_128_CCM (0xc09c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 91
Extension: server_name (len=17)
Type: server_name (0)
Length: 17
Server Name Indication extension
Server Name list length: 15
Server Name Type: host_name (0)
Server Name length: 12
Server Name: api.nike.com
Extension: ec_point_formats (len=4)
Type: ec_point_formats (11)
Length: 4
EC point formats Length: 3
Elliptic curves point formats (3)
Extension: supported_groups (len=10)
Type: supported_groups (10)
Length: 10
Supported Groups List Length: 8
Supported Groups (4 groups)
Extension: session_ticket (len=0)
Type: session_ticket (35)
Length: 0
Data (0 bytes)
Extension: encrypt_then_mac (len=0)
Type: encrypt_then_mac (22)
Length: 0
Extension: extended_master_secret (len=0)
Type: extended_master_secret (23)
Length: 0
Extension: signature_algorithms (len=32)
Type: signature_algorithms (13)
Length: 32
Signature Hash Algorithms Length: 30
Signature Hash Algorithms (15 algorithms)
You can downgrade to tls1.2 by specifying method "TLSv1_2_method":
var https = require('https');
var options = {
hostname: 'example.com',
port: 443,
path: '/',
method: 'GET',
secureProtocol:'TLSv1_2_method'
};
const req = https.request(options, (res) => {
console.log('statusCode:', res.statusCode);
console.log('headers:', res.headers);
res.on('data', (d) => {
process.stdout.write(d);
});
});
And if the server is part of your project I would advice to fix server side instead of crippling your client app.
stack: nodejs4, chai,jdom. The objective is to write a test that interrogates the HTML of a URL in a web application which is only accessible over SSL in the corporate intranet.
I am writing a mocha test using jsdom and I get the SSL certificate error:
{ Error: unable to verify the first certificate
at Error (native)
at TLSSocket.<anonymous> (_tls_wrap.js:1060:38)
at emitNone (events.js:86:13)
at TLSSocket.emit (events.js:185:7)
at TLSSocket._finishInit (_tls_wrap.js:584:8)
at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:416:38)
code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE' }
I have the following test code:
var chai = require('chai');
var jsdom = require('jsdom');
var expect = chai.expect;
https = require('https');
fs = require('fs');
var cas = require('ssl-root-cas/latest').inject().addFile('test/ssl/key.pem').addFile('test/ssl/server.crt');
//process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
https.globalAgent.options.ca = cas;
jsdom.env(
"https://www.example.com",
['https://www.example.com/jquery-1.10.2.js'],
function(err, window) {
if(err){
console.log(err);
} else {
console.log("contents of the research project input box is:", window.$("#field_cell_1840 input.custom-combobox-input").text());
}
}
);
I have generated the keys in test/ssl like this:
openssl req -newkey rsa:2048 -new -nodes -keyout key.pem -out csr.pem
openssl x509 -req -days 365 -in csr.pem -signkey key.pem -out server.crt
I have followed various threads and tried suggestions in https://github.com/coolaj86/node-ssl-root-cas including bad ideas such as the use of process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0"
When I do a curl -vk https://www.example.com then I get the following output:
ac2f15#UOS-012145 ~/git/NodeJS/test (master)
$ curl -vk https://www.example.com
* Rebuilt URL to: www.example.com
* timeout on name lookup is not supported
* Trying 192.168.168.116...
* Connected to www.example.com (192.168.168.116) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.0 (IN), TLS handshake, Server hello (2):
* TLSv1.0 (IN), TLS handshake, Certificate (11):
* TLSv1.0 (IN), TLS handshake, Server key exchange (12):
* TLSv1.0 (IN), TLS handshake, Server finished (14):
* TLSv1.0 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.0 (OUT), TLS change cipher, Client hello (1):
* TLSv1.0 (OUT), TLS handshake, Finished (20):
* TLSv1.0 (IN), TLS change cipher, Client hello (1):
* TLSv1.0 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.0 / DHE-RSA-AES256-SHA
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: OU=Domain Control Validated; CN=sitepublisher-dev.soton.ac.uk
* start date: Dec 9 00:00:00 2014 GMT
* expire date: Dec 8 23:59:59 2017 GMT
* issuer: C=NL; ST=Noord-Holland; L=Amsterdam; O=TERENA; CN=TERENA SSL CA 2
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> Host: srv00700.soton.ac.uk
> User-Agent: curl/7.46.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Mon, 10 Oct 2016 16:09:05 GMT
< Server: Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/0.9.8e-fips-rhel5
< Location: https://www.example.com/
< Content-Length: 358
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
My question is, is there someone who has done a successful chai test using jdom on a https URL ? If so, could you please share your experience with me?