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
next 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