All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.