As I am thinking about this a little more - I guess that the SSL_new and SSL_accept handles all of the SSL handshake negotiation as well, that would have to be manually handled if you were trying to decrypt on the fly?
On Wed, Oct 31, 2012 at 2:23 PM, Derek Cole <derek.c...@gmail.com> wrote: > To be clear - I have already written the code to read the SSL header. > > Regarding your last line - is there a cleaner way to "redirect" as you > say, or is it as I described - opening a new socket and writing the packet > to it? > > If I wanted to decrypt on the fly, is there a standard way of decrypting > the TCP payload "automatically" as the SSL socket does when you stand up a > SSL_CTX and use SSL_new with that context? > > > > > > On Wed, Oct 31, 2012 at 2:06 PM, dreamwvr <dream...@dreamwvr.com> wrote: > >> On 10/31/12 11:21 AM, Derek Cole wrote: >> >>> Hello, >>> >>> Is it possible to use libpcap to detect an incoming connection (writing >>> all packets those packets to a socket), >>> >> Yes >> >> then, if using libpcap i determine that a SSL connection was established >>> , >>> >> Then check if it has a SSL header reading the header >> https://en.wikipedia.org/wiki/**Transport_Layer_Security#TLS_** >> handshake_in_detail<https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake_in_detail> >> >> stand up another socket to read the same file descriptor with the SSL >>> client so that I could use the proper context and such to decrypt it? >>> >>> THanks >>> >> Then redirect to another socket or dup to >> decrypting on the fly.. although it did work well for the fly.. not so >> well the other guy:-) >> >> >> >
