Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am trying to communicate with an SSL server whose protocol is non-standard. I want to insert custom packets into the handshake. I am using several SSL tools, so changing source code on every tool is a lot of work. Prefer to have a network filter which will modify (insert a custom packet) into every SSL handshake.

Tried netsed. No go. It can modify existing packets, but not insert a new packet.

Tried ncat. No go. It can insert a packet, but when we launch SSL tool, a second TCP session is set up. Tried many variations. This is the root of the problem: how can I insert packets into the middle of an SSL handshake session (without starting a separate TCP session)?

share|improve this question
    
Are you aware of any proxies that will interact with this non-standard SSL server? For example can you get stunnel to connect to it? –  Zoredache Mar 27 '13 at 22:58
add comment

1 Answer

In a SSL handshake, the client and the server exchange handshake messages which are encoded in records. If your protocol variant consists in additional handshake messages then you have a problem: at the end of the handshake, two Finished messages are exchanged, and their contents are computed as a hash function over all previous handshake messages, therefore including your extra messages. Corollary: if you have extra handshake messages to insert, you MUST modify the SSL client tool, because that tool computes the hash and will compute a wrong value if it is not aware of your extra messages.

If your protocol variant consists in extra records of a type distinct from "record for handshake messages" (type 22 in the standard), and such that the extra records do not impact the computations of the handshake, then your filter strategy might work. You would have to:

  1. Intercept connections; there are several ways for that, but the simplest is to change the configuration and/or DNS so that the source machine connects not to the target server, but to a server of your own, which itself connects to the rightful server, and relays data in both direction.

  2. Parse the data so that you detect the handshake records, to know where and when your extra messages must be added in the flow (and, similarly, extra messages from the server must be analysed and removed, so that the SSL client tool does not choke on them).

So you are in for some programming. The record protocol of SSL is not complex, as long as you fiddle with the unencrypted records (those before the completion of the handshake); see the section 6 of the standard. Also, see this answer for a detailed introduction on the protocol (which I believe to be easier to read than the standard). For the relaying, the simplest implementation strategy would probably to launch two threads, each thread running in an endless loop of read-from-one-machine-write-to-the-other.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.