making requests to https://google.com errors

[azylman]

This happens for me in node v0.8.12 and v0.8.19 on two different machines, one Ubuntu 12.04 and one OSX 10.8. It doesn't happen if I make requests to other domains.

var https = require('https');
https.request('https://google.com', function(res) {console.log(res)});

Produces:

events.js:68
        throw arguments[1]; // Unhandled 'error' event
                       ^
Error: 140463203215168:error:0607907F:digital envelope routines:EVP_PKEY_get1_RSA:expecting an rsa key:../deps/openssl/openssl/crypto/evp/p_lib.c:288:

    at CleartextStream._pusher (tls.js:656:24)
    at SlabBuffer.use (tls.js:199:18)
    at CleartextStream.CryptoStream._push (tls.js:483:33)
    at SecurePair.cycle (tls.js:880:20)
    at SecurePair.cycle (tls.js:895:10)
    at EncryptedStream.CryptoStream.write (tls.js:267:13)
    at Socket.ondata (stream.js:38:26)
    at Socket.EventEmitter.emit (events.js:93:17)
    at TCP.onread (net.js:396:14)

[bnoordhuis]

Sorry, can't reproduce. Works for me with master and v0.8.

[rodrigoalvesvieira]

@azylman Couldn't that be a problem with your local openssl program? Have you tested it for other HTTPS urls?

Tested here on Mac OSX Mountain Lion and everything is fine.

[azylman]

@rodrigoalvesvieira I did test it with other HTTPS URLs and it only failed hitting Google. I'm not sure how it could be a problem with my local openssl program when I tried it on two different machines with two different versions of OpenSSL. Their versions of openssl were: OpenSSL 0.9.8r 8 Feb 2011 and OpenSSL 1.0.1 14 Mar 2012.

I asked one of my coworkers to confirm and he sees the same behavior, so this is not an isolated incident...

[bnoordhuis]

Different machines but the same network? Check that there's not some kind of firewall or proxy causing interference.

[azylman]

I've reproduced it on three different networks so far. On an AWS machine, on our office network, and also while tethering on Verizon's 4G network.

[AlexeyKupershtokh]

I have the same issue when trying to work with google under xubuntu 12.10 and nodejs v0.8.19-0.8.20.

events.js:71
        throw arguments[1]; // Unhandled 'error' event
                       ^
Error: 140423179986752:error:0607907F:digital envelope routines:EVP_PKEY_get1_RSA:expecting an rsa key:../deps/openssl/openssl/crypto/evp/p_lib.c:288:

    at CleartextStream._pusher (tls.js:674:24)
    at SlabBuffer.use (tls.js:217:18)
    at CleartextStream.CryptoStream._push (tls.js:501:33)
    at SecurePair.cycle (tls.js:898:20)
    at SecurePair.cycle (tls.js:913:10)
    at EncryptedStream.CryptoStream.write (tls.js:285:13)
    at Socket.ondata (stream.js:38:26)
    at Socket.EventEmitter.emit (events.js:96:17)
    at TCP.onread (net.js:397:14)

[corywilkerson]

Seeing this on Mountain Lion 10.8.2 and nodejs v0.8.20

> var options = { 
    hostname: 'gdata.youtube.com', 
    port: 443, 
    path:'/feeds/api/playlists/snippets?q=GoogleDevelopers', 
    headers: { 'User-Agent':'youtube-feeds.js (https://github.com/fvdm/nodejs-youtube)', 'Accept': 'application/json' }, 
    method: 'GET' 
}

> var request = https.request( options, function(res) { console.log(res) });

events.js:71
        throw arguments[1]; // Unhandled 'error' event
                       ^
Error: 140735290048896:error:0607907F:digital envelope routines:EVP_PKEY_get1_RSA:expecting an rsa key:../deps/openssl/openssl/crypto/evp/p_lib.c:288:

    at CleartextStream._pusher (tls.js:674:24)
    at SlabBuffer.use (tls.js:217:18)
    at CleartextStream.CryptoStream._push (tls.js:501:33)
    at SecurePair.cycle (tls.js:898:20)
    at SecurePair.cycle (tls.js:913:10)
    at EncryptedStream.CryptoStream.write (tls.js:285:13)
    at Socket.ondata (stream.js:38:26)
    at Socket.EventEmitter.emit (events.js:96:17)
    at TCP.onread (net.js:397:14)

[AlexeyKupershtokh]

And Ubuntu 11.04 + node 0.8.19-1chl1natty1 and 0.8.20-1chl1natty1 (i386, from chris lea's ppa) on my office pc has the same issue in both cases from @corywilkerson and @azylman

Though Ubuntu 10.04.4 LTS + node v0.8.16-1chl1lucid1 and 0.8.20-1chl1lucid1 (amd64, also from chris lea's ppa) work well on a server located in a DC.

[AlexeyKupershtokh]

Reopen maybe?

[bnoordhuis]

For some reason it reproduces for me now (with google.com - but not www.google.com).

[AlexeyKupershtokh]

I've also noticed this. This could probably be related:

wicked@wicked-desktop:/$ wget -S https://google.com/
--2013-02-19 18:46:12--  https://google.com/
Resolving google.com... 74.125.143.138, 74.125.143.139, 74.125.143.100, ...
Connecting to google.com|74.125.143.138|:443... connected.
ERROR: certificate common name `*.google.com' doesn't match requested host name `google.com'.
To connect to google.com insecurely, use `--no-check-certificate'.

But this does not explain why does node still crash on an https://play.google.com/ url.

[abarron87]

I am getting the same issue with the YouTube data API, it worked yesterday afternoon but coming in the morning I see:

Error: 140735247131008:error:0607907F:digital envelope routines:EVP_PKEY_get1_RSA:expecting an rsa key:../deps/openssl/openssl/crypto/evp/p_lib.c:288

Running node 0.8.15

Hostname: "gdata.youtube.com"
Path: "/feeds/api/videos?q=arsenal&orderby=relevance&v=2&alt=json&max-results=2&key="+apiKey

Requests work in the browser.

[agl]

Reproducibility for this issue will vary because of differing configs across our frontend clusters and for different domains. However, over time, I expect increasing amounts of Google and non-Google services to stop working because of this.

The wget issue noted above is due to a deficiency in wget (lack of SNI support) and is unrelated.

I think the problem arises from a failure to clear the OpenSSL error stack in node_crypto.cc:

EVP_PKEY *pkey = NULL;
RSA *rsa = NULL;
if( NULL != (pkey = X509_get_pubkey(peer_cert))
    && NULL != (rsa = EVP_PKEY_get1_RSA(pkey)) ) {
    BN_print(bio, rsa->n);

When EVP_PKEY_get1_RSA fails it will leave an error on the stack and that appears to be popping up later in processing.

I cannot reproduce this on master and I bisected the fix to d59beb9. However, that's a wider ranging change that likely fixed the issue by accident or, possibly, masked it for a little longer.

As a smaller change that can be back-ported, I'd suggest checking that the public key is an RSA key before calling EVP_PKEY_get1_RSA:

EVP_PKEY *pkey = NULL;
RSA *rsa = NULL;
if( NULL != (pkey = X509_get_pubkey(peer_cert))
    && EVP_PKEY_RSA == EVP_PKEY_id(pkey)
    && NULL != (rsa = EVP_PKEY_get1_RSA(pkey)) ) {
    BN_print(bio, rsa->n);

(Note the extra clause in the condition.)

That fixes the proximal issue for me although the problem of not cleaning the OpenSSL error stack appears to be more pervasive.