Linux Netfilter discussions
 help / color / mirror / Atom feed
From: herraffe <herraffe@freenet.de>
To: netfilter@vger.kernel.org
Subject: Modify SSL packets with Scapy
Date: Sun, 03 May 2015 19:58:40 +0200	[thread overview]
Message-ID: <554661D0.3010903@freenet.de> (raw)

Hi,
currently I am trying to modify SSL Client Hello packets that are sent 
from client A to server B.
I have set up iptables to move packets into nfqueue:
iptables -t mangle -A PREROUTING -p tcp --dport 443 -j NFQUEUE
Here is the definition of the callback function for the received SSL 
packets:
def callback(i,payload):
   data = payload.get_data()
   pkt = IP(data)

   if pkt.haslayer(SSLv2ClientHello):
     pkt.show()

   payload.set_verdict(nfqueue.NF_ACCEPT)

  So far everything works fine, if I create a SSL connection between A 
and B, the packets get redirected through the nfqueue. If the Client 
Hello shows up, it will be displayed. It should also be noted that I use 
the scapy-ssl_tls library (https://github.com/tintinweb/scapy-ssl_tls) 
to get a SSL layer for scapy.
But displaying Client Hello is not everything I want to do, I actually 
want to modify it. So I tried the following:
def callback(i,payload):
   data = payload.get_data()
   pkt = IP(data)

   if pkt.haslayer(SSLv2ClientHello):
     pkt.show()

   ret = payload.set_verdict_modified(nfqueue.NF_ACCEPT, str(pkt), len(pkt))
   print ("ret = {}".format(ret))

This should not modify the packet at all. Basically I just use 
set_verdict_modified instead of set_verdict. I used this simple test to 
see if the method that I will need later on, for real modification, 
works. Also there is no need to recompute the length or checksum (at 
least I think so). But now the trouble begins, If I create a SSL 
connection between A and B, the connection will not be established. The 
method returns "88" (I could not find a source to figure out what that 
means) and Wireshark shows a lot of TCP Retransmissions for Client Hello.

My guess is that the packet gets modified somehow and therefore a manual 
forward (set_verdict_modified) does not work, whereas the automatic 
forwarding (set_verdict) does work because the packet is not modified. 
Hopefully someone can help me with this quite specific problem.

Best regards,
mint

             reply	other threads:[~2015-05-03 17:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-03 17:58 herraffe [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-05-03 18:11 Modify SSL packets with Scapy Hubert Strauß

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=554661D0.3010903@freenet.de \
    --to=herraffe@freenet.de \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox