Re: Reverse engineering program protocol under ssl
MacDermid, Kenny wrote: I'm looking to locally reverse engineer a network protocol > that's encrypted using ssl. The program runs under windows and > is using ssl dll's. I'm currently trying to work out the easiest solution, and am looking for suggestions. I'm considering either trying to wrap the dll's to read data > passed to/from ssl_read/ssl_write, or recompiling the dll's to print > the key after the key exchange. Can anyone think of a better way to do > this? I can't be the first person looking for this, but I looked through > the archive, and online, to no avail. Any ideas? Another method would be to use a man-in-the-middle attack on a third machine, but that machine would need access to the private key of the certificate to be used. Somewhere around I have a generic man-in-the-middle Unix program that I wrote to try to debug some early IMAP problems on the Handspring Visor, but it doesn't have any SSL. -- "An Internet-connected Windows machine is tantamount to a toddler carrying a baggie of $100 bills down a city street..." Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Reverse engineering program protocol under ssl
http://www.rtfm.com/ssldump/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Reverse engineering program protocol under ssl
> From: Peter Sylvester > > http://www.rtfm.com/ssldump/ Thank you for your reply Peter, Unfortunately I already looked into this, and found that I would need the server keys. All I have is the client application, and a production server that it communicates back to. Thanks again, Kenny -- Outgoing mail is certified Virus Contaminated: [EMAIL PROTECTED](P^)7CC)7$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* Checked by AVG Anti-Virus. Version: 7.0.290 / Virus Database: 265.4.1 - Release Date: 19/11/2004 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Reverse engineering program protocol under ssl
> From: Charles B Cranston > > MacDermid, Kenny wrote: > > I'm looking to locally reverse engineer a network protocol > > that's encrypted using ssl. > > Another method would be to use a man-in-the-middle attack on > a third machine, but that machine would need access to the > private key of the certificate to be used. Somewhere around > I have a generic man-in-the-middle Unix program that I wrote > to try to debug some early IMAP problems on the Handspring > Visor, but it doesn't have any SSL. I don't actually have access to the server, or the private key it is using. Also I'm guessing the client is smart enough to check the server certificate, so I'm guessing a generic man-in-the-middle is out. Thank you for the reply Charles, Kenny -- Outgoing mail is certified Virus Contaminated: [EMAIL PROTECTED](P^)7CC)7$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* Checked by AVG Anti-Virus. Version: 7.0.290 / Virus Database: 265.4.1 - Release Date: 19/11/2004 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Reverse engineering program protocol under ssl
On Wed, Nov 24, 2004, MacDermid, Kenny wrote: > > From: Charles B Cranston > > > > MacDermid, Kenny wrote: > > > I'm looking to locally reverse engineer a network protocol > > > that's encrypted using ssl. > > > > Another method would be to use a man-in-the-middle attack on > > a third machine, but that machine would need access to the > > private key of the certificate to be used. Somewhere around > > I have a generic man-in-the-middle Unix program that I wrote > > to try to debug some early IMAP problems on the Handspring > > Visor, but it doesn't have any SSL. > > I don't actually have access to the server, or the private key > it is using. Also I'm guessing the client is smart enough to > check the server certificate, so I'm guessing a generic > man-in-the-middle is out. > > I haven't followed this thread too closely. Does the client use OpenSSL? If so you only need to replace the DLL with one that logs the data handled by SSL_read() and SSL_write(). If CryptoAPI is used there are various ways to obtain the unencrypted premaster secret and use that to decrypt the session. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Reverse engineering program protocol under ssl
in openssl/apps/s_client;c you find: if (c_debug) { con->debug=1; BIO_set_callback(sbio,bio_dump_cb); BIO_set_callback_arg(sbio,bio_c_out); } if (c_msg) { SSL_set_msg_callback(con, msg_cb); SSL_set_msg_callback_arg(con, bio_c_out); } This and s_cb.c might help you. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Reverse engineering program protocol under ssl
You're quite welcome. I'm sure the journalling-DLL approach would work just as well. Just for information, if you have administrative access to the server and it is based on Windows, you might be able to save the certificate and key as a .pfx file, then use the OpenSSL pkcs12 command to extract the key. If you have the key, you could use a very simple man in the middle program that just passes the data through. It would not know what it is seeing, but later you could postprocess the dump with the known key and decrypt the traffic. Under Unix a man in the middle program can be done one of three ways: A1: forever { if nonblockingread(a) write(b) if nonblockingread(b) write(a) } A2: forever { select(a,b) if (select(hastraffic,a) and select(canwrite,b) {read(a) write(b)} if (select(hastraffic,b) and select(canwrite,a) {read(b) write(a)} } B: fork(another) forever { blockingread(a) write(b) } another: forever { blockingread(b) write(a) } I belive the one I wrote followed pattern A2. If you just copy and journal bytes any of these would work fine. Now, if you want to actually do SSL on the links, so the man in the middle program is getting decrypted data, one of these might be easier given the restrictions of the OpenSSL read and write primitives. I believe there are some difficulties with nonblocking IO. Are there also some difficulties with select? For the fork case, I suspect using different processes is more safe than using different threads. Is the OpenSSL stuff thread-safe? MacDermid, Kenny wrote: From: Charles B Cranston MacDermid, Kenny wrote: I'm looking to locally reverse engineer a network protocol that's encrypted using ssl. Another method would be to use a man-in-the-middle attack on a third machine, but that machine would need access to the private key of the certificate to be used. Somewhere around I have a generic man-in-the-middle Unix program that I wrote to try to debug some early IMAP problems on the Handspring Visor, but it doesn't have any SSL. I don't actually have access to the server, or the private key it is using. Also I'm guessing the client is smart enough to check the server certificate, so I'm guessing a generic man-in-the-middle is out. Thank you for the reply Charles, Kenny -- "An Internet-connected Windows machine is tantamount to a toddler carrying a baggie of $100 bills down a city street..." Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Reverse engineering program protocol under ssl
> From: MacDermid, Kenny > Sent: Wednesday, November 24, 2004 8:33 AM > To: [EMAIL PROTECTED] > Subject: RE: Reverse engineering program protocol under ssl > > > > From: Peter Sylvester > > > > http://www.rtfm.com/ssldump/ > > Thank you for your reply Peter, > > Unfortunately I already looked into this, and found that I > would need the > server keys. All I have is the client application, and a production > server that it communicates back to. I would assume the client is simply checking that the server certificate matches the hostname and is properly signed by a trusted root. My application performs a man in the middle by first examining known root stores and adding its own CA. The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Reverse engineering program protocol under ssl
Actually, I'm trying to do this very thing. I had not heard of ssldump and now I'm kicking myself. You should definitely use this ssldump thing. What I was eventually going to do, which you could do also, is find out what address is the call to SSL_verify or whatever that checks the integrity of signed certificates, and replace it with a move $1,%eax or something... you get the point. Or search for certificate like strings in the executable or use something like pedump. (I"m assuming this is a windows program, linux programmers don't encrypt their protocols), and then you can pull out the certificate that the client uses to make sure its talking to the right server instead of to, in this case, ssldump. Unfortunately, I'm too far gone to use ssldump, I already have a complete TCP stack and though it annoys me to find out that yes, such a program like I am writing exists, it can't be quite as hardcore can it? Good luck though. - Peter __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Reverse engineering program protocol under ssl
> > > From: Charles B Cranston > > > > MacDermid, Kenny wrote: > > > I'm looking to locally reverse engineer a network protocol > > > that's encrypted using ssl. > > > > Another method would be to use a man-in-the-middle attack on > > a third machine, but that machine would need access to the > > private key of the certificate to be used. Somewhere around > > I have a generic man-in-the-middle Unix program that I wrote > > to try to debug some early IMAP problems on the Handspring > > Visor, but it doesn't have any SSL. > > I don't actually have access to the server, or the private key > it is using. Also I'm guessing the client is smart enough to > check the server certificate, so I'm guessing a generic > man-in-the-middle is out. If you can't compromise either the client or the server in some way, you cannot decrypt the data. That's the whole point of SSL. You will have to get the data out of the client application directly. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]