I've got a problem with SSL in 7.5. I get a mac verification failure when running an sslport. Any idea what might be going on? I'm pretty sure the other end is not a problem, as it's a pretty well known service that's trying to make the connection (paypal). I've included a copy of the relevent debug output, attached below. Any ideas what might be going on? (this is a recent checkout, maybe from yesterday).
Bill
SSL.packet->recv: received version 3.1 packet Decrypting packet.. version[1]=1 SSL.connection: received packet of type 22 client_key_exchange server_derive_master_secret: ke_method 1 encrypted premaster_secret: "\0@;\262\375\4\366\310\334\262\343\337\214\272o\205>\224\37\375\3n\31\n\223Xb{vW\375;\356\345?m)\240""4\266\315d\17p1\206\177{4g\374 \274\310\n}L\27N?\311\36V5\371\350" premaster_secret: "\3\1\231\37G\3\353\214\371\27"\U\226x\343\37\371a>7\264Xu\323H\a\27\34D\304hb\364\303\321g\244\201\234DM\233\304\331\266\fa" SSL.handshake: Newer version detected in key exchange message. master: "\1yER\251""8*\371Xu\310\255\311\375.\241\6\372?WxK;:k\365\316]\241\272\343~[`B\234&\377\372w\320*\t\265T\a\3M" key_block: "T\354""1\261;\315\257LH0D\255\242c\211\23@\212\37\222`\\214`|Gu\261i.\37\f|\4p@\316\346@\34A` b\203\373\211<\1\311E}\356\356\21LH\223z\345?\33\351\35S\201=:\27i{\247\235F\302$\262%'r\0\31v\371\37\321\364\247" client_random: "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\367_0\300}\367\225x%\271*\16\4E>\203" server_random: "@Py\351\340\234i7\316\247\246R5\300"\240\302qw\25\4\242\220\223\333\225\322\261\275\344\306\340" client_write_MAC_secret: len:20 type:0 54 ec 31 b1 3b cd af 4c 48 30 44 ad a2 63 89 13 40 8a 1f 92 server_write_MAC_secret: len:20 type:0 60 5c 8c 60 7c 47 75 b1 69 2e 1f 0c 7c 04 70 40 ce e6 40 1c keys[2]: len:16 type:0 41 60 20 62 83 fb 89 3c 01 c9 45 7d ee ee 11 4c keys[3]: len:16 type:0 48 93 7a e5 3f 1b e9 1d 53 81 3d 3a 17 69 7b a7 keys[4]: len:8 type:0 9d 46 c2 24 b2 25 27 72 keys[5]: len:8 type:0 00 19 76 f9 1f d1 f4 a7 certificate_state: 0 SSL.packet->recv: received version 3.1 packet Decrypting packet.. version[1]=1 SSL.connection: received packet of type 20 tried change_cipher: 0 SSL.packet->recv: received version 3.1 packet Decrypting packet.. version[1]=1 Failed MAC-verification!! SSL.connection: Bad received packet SSL.connection->send_packet: type 21, desc 20, pri 1, "\2\24"
I updated to the latest CVS code, and the problem still seems to be around. However, I do have some more details:
Without fiddling with the cipher suites, the handshake selects IDEA as the bulk cipher with sha1 mac. It seems that the packet isn't getting decrypted, yielding a decrypted packet fragment of "". If I remove IDEA as a valid bulk cipher, the handshake selects RC4, and I no longer get an empty decoded packet, but the decode is gibberish.
It would seem to me that somewhere the key is incorrect or the data is getting shifted so that we're not decoding the same data that was encrypted.
While the code does work with the Pike ssl client and mozilla, there's definitely something fishy when it comes to other clients (I'm guessing that they're using something openssl derived at paypal).
Any thoughts?
Bill
/ hww3
Previous text:
Well, it doesn't work with 7.4.28:
SSL.packet->recv: received version 3.1 packet Decrypting packet.. version[1]=1 SSL.state->decrypt_packet: data = "\1" SSL.state: Decrypted_packet "\1" SSL.connection: received packet of type 20 tried change_cipher: 0 SSL.packet->recv: received version 3.1 packet Decrypting packet.. version[1]=1 SSL.state->decrypt_packet: data = "^\304\373P\331\371\336i\213\23\226\234\260\247\356\220\307\346\\n\300\321,\327W\206" \212\370o}\263\1\204\323\205b(L" SSL.state: Trying decrypt.. strlen of the encrypted packet is:40 Incorrect padding detected!!! SSL.state: Decrypted_packet "\27\235\21g\36\242\301\360\304\332\266\245\274\312\336\325\230\340U\251 \372\6\360\1<\26\213\16\341\335\16\245\222\270\366\265\264\352\333" SSL.state: Trying mac verification... Failed MAC-verification!! SSL.connection: Bad received packet SSL.connection->send_packet: type 21, 1, '"\2\24"' SSL.sslfile->die: is_closed = 0 SSL.context->purge_session: "" SSL.sslfile: Killed
But, it seems to think the padding is incorrect. I guess I'll need to look to see where that's coming from.
Bill
I've done some more analysis, and it appears that the decrypt key is wrong, as pike seems to be trying to decrypt the correct data. This makes me thing that something's funny in the key exchange, but I'm not knowledgable enough to know if it's working properly.
Anyone have any experience in these matters?
Bill
/ hww3
Previous text:
pike-devel@lists.lysator.liu.se