Re: [tcpdump-workers] Decoding the unencrypted part(s) of SSL/TLS?
On Mon, Dec 10, 2012 at 11:38:29PM -0500, Michael Richardson wrote: > > > "Rick" == Rick Jones writes: > Rick> Is there a version of tcpdump in the works which will decode > Rick> the unecrypted > Rick> portions of an SSL/TLS session? Or do I need to look > Rick> elsewhere? Are you asking if there is a decoder for the SSL/TLS handshakes or are you asking if there is something that will, given a private key, decrypt the SSL? > Yes/no. > You have, in general, to do TCP reassembly as TLS blocks might span TCP > segments. > > Fortunately, you can use: http://www.rtfm.com/ssldump/ > to do exactly that. There are some problems with ssldump when building on newer-ish systems (at least I think there were last time I tried to use it). If you can get it to work it is good. > It takes pcap files. It even decrypts if you give it the keys. Another option is to use tshark. I'm not a fan of it but it does work in a pinch. -- WXS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
On Tue, 2012-12-11 at 14:36 -0800, Ani Sinha wrote:
> >
> > It is possible to test for the presence of support of the new vlan bpf
> > extensions by attempting to load a filter that uses them. As only valid
> > filters can be loaded, old kernels that do not support filtering of vlan
> > tags will fail to load the a test filter with uses them.
>
> Unfortunately I do not see this. The sk_chk_filter() does not have a
> default in the case statement and the check will not detect an unknown
> instruction. It will fail when the filter is run and as far as I can see,
> the packet will be dropped. Something like this might help?
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index c23543c..96338aa 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -548,6 +548,8 @@ int sk_chk_filter(struct sock_filter *filter, unsigned
> int flen)
> return -EINVAL;
> /* Some instructions need special checks */
> switch (code) {
> + /* for unknown instruction, return EINVAL */
> + default : return -EINVAL;
> case BPF_S_ALU_DIV_K:
> /* check for division by zero */
> if (ftest->k == 0)
This patch is wrong.
Check lines 546, 547, 548 where we do the check for unknown instructions
code = codes[code];
if (!code)
return -EINVAL;
If you want to test ANCILLARY possible values, its already too late, as
old kernels wont use any patch anyway.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
On 12/12/2012 10:53 PM, Ani Sinha wrote:
unsigned int netdev_8021q_inskb = 1;
...
{
.ctl_name = NET_CORE_8021q_INSKB,
.procname = "netdev_8021q_inskb",
.data = &netdev_8021q_inskb,
.maxlen = sizeof(int),
.mode = 0444,
.proc_handler = proc_dointvec
},
would seem to do it to me.
Then pcap can fopen("/proc/sys/net/core/netdev_8021q_inskb") and if it
finds it, and it is >0, then do the cmsg thing.
Does this work? This is just an experimental patch and by no means final.
I just want to have an idea what everyone thought about it. Once we debate
and discusss, I can cook up a final patch that would be worth commiting.
Also instead of having this /proc interface, we can perhaps check for a
specific
kernel version that :
(a) has the vlan tag info in the skb metadata (as opposed to in the packet
itself)
(b) has the following patch that adds the capability to generate a filter
based on the tag value :
commit f3335031b9452baebfe49b8b5e55d3fe0c4677d1
Author: Eric Dumazet
Date: Sat Oct 27 02:26:17 2012 +
net: filter: add vlan tag access
WE need both of the above two things for the userland to generate a filter
code that compares vlan tag values in the skb metadata. For kernels that
has the vlan tag in
the skb metadata but does not have the above commit (b), there is nothing
that can be done. For older kernels that had the vlan tag info in the
packet itself, the filter code can be generated differently to look at
specific offsets within the packet (something that libpcap does
currently).
We have already ruled out the idea of generating a filter and trying to
load and see if that fails (see previous emails on this thread).
Hope this makes sense.
I think it doesn't. Because then you are obviously considering adding one
procfs file into /proc/sys/net/core/ *for each* feature that is added into
the ancillary ops which cannot be the right way ...
diff --git a/include/linux/filter.h b/include/linux/filter.h
index c45eabc..91e2ba3 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -36,6 +36,7 @@ static inline unsigned int sk_filter_len(const struct
sk_filter *fp)
return fp->len * sizeof(struct sock_filter) + sizeof(*fp);
}
+extern bool sysctl_8021q_inskb;
extern int sk_filter(struct sock *sk, struct sk_buff *skb);
extern unsigned int sk_run_filter(const struct sk_buff *skb,
const struct sock_filter *filter);
diff --git a/net/core/filter.c b/net/core/filter.c
index c23543c..4f5a657 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -41,6 +41,8 @@
#include
#include
+bool sysctl_8021q_inskb = 1;
+
/* No hurry in this branch
*
* Exported for the bpf jit load helper.
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index d1b0804..f9a3700 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -189,6 +190,13 @@ static struct ctl_table net_core_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "8021q_inskb",
+ .data = &sysctl_8021q_inskb,
+ .maxlen = sizeof(bool),
+ .mode = 0444,
+ .proc_handler = proc_dointvec
+ },
{ }
};
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
On Tue, 11 Dec 2012 14:36:33 -0800 (PST)
Ani Sinha wrote:
> >
> > It is possible to test for the presence of support of the new vlan bpf
> > extensions by attempting to load a filter that uses them. As only valid
> > filters can be loaded, old kernels that do not support filtering of vlan
> > tags will fail to load the a test filter with uses them.
>
> Unfortunately I do not see this. The sk_chk_filter() does not have a
> default in the case statement and the check will not detect an unknown
> instruction. It will fail when the filter is run and as far as I can see,
> the packet will be dropped. Something like this might help?
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index c23543c..96338aa 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -548,6 +548,8 @@ int sk_chk_filter(struct sock_filter *filter, unsigned
> int flen)
> return -EINVAL;
> /* Some instructions need special checks */
> switch (code) {
> + /* for unknown instruction, return EINVAL */
> + default : return -EINVAL;
> case BPF_S_ALU_DIV_K:
> /* check for division by zero */
> if (ftest->k == 0)
Did you test this? I think it will blow up for some existing instructions
like BPF_S_ALU_XOR_X or any of the other non-special instructions.
Also it is not formatted correctly for the kernel programming style.
ERROR: space prohibited before that ':' (ctx:WxW)
#86: FILE: net/core/filter.c:552:
+ default : return -EINVAL;
^
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
On Thu, Dec 13, 2012 at 12:35 AM, Daniel Borkmann wrote:
> On 12/12/2012 10:53 PM, Ani Sinha wrote:
>>>
>>> unsigned int netdev_8021q_inskb = 1;
>>>
>>> ...
>>> {
>>> .ctl_name = NET_CORE_8021q_INSKB,
>>> .procname = "netdev_8021q_inskb",
>>> .data = &netdev_8021q_inskb,
>>> .maxlen = sizeof(int),
>>> .mode = 0444,
>>> .proc_handler = proc_dointvec
>>> },
>>>
>>> would seem to do it to me.
>>> Then pcap can fopen("/proc/sys/net/core/netdev_8021q_inskb") and if it
>>> finds it, and it is >0, then do the cmsg thing.
>>>
>>
>
> I think it doesn't. Because then you are obviously considering adding one
> procfs file into /proc/sys/net/core/ *for each* feature that is added into
> the ancillary ops which cannot be the right way ...
We had already brought up this topic previously in the same thread. A
suggestion was made to add that proc entry and no one from netdev
responded to it saying that it did not make any sense. Therefore
before I went ahead and made the fixes in libpcap, I wanted to run
this by your guys again to make sure we are still on the same page.
I do agree that instead of a /proc entry, we should check for a kenrel
version >= X where X is the upstream version that first started
supporting all the features needed by libpcap for vlan filtering. This
is not a compile time check but a run time one. Does anyone see any
issues with this? Is there any long term implications of this, like if
you backport patches to an older long term supported kernel? Are there
other better ways to do this, like may be returning feature bits from
an ioctl call? This is something we need to deal with on a continuous
basis as we keep supporting newer AUX fields and libpcap and other
user land code needs to make use of it. At the same time, they need to
handle backward compatibility issues with older kernels.
Thanks
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
On Thu, Dec 13, 2012 at 6:34 PM, Ani Sinha wrote:
> On Thu, Dec 13, 2012 at 12:35 AM, Daniel Borkmann wrote:
>> On 12/12/2012 10:53 PM, Ani Sinha wrote:
unsigned int netdev_8021q_inskb = 1;
...
{
.ctl_name = NET_CORE_8021q_INSKB,
.procname = "netdev_8021q_inskb",
.data = &netdev_8021q_inskb,
.maxlen = sizeof(int),
.mode = 0444,
.proc_handler = proc_dointvec
},
would seem to do it to me.
Then pcap can fopen("/proc/sys/net/core/netdev_8021q_inskb") and if it
finds it, and it is >0, then do the cmsg thing.
>>
>> I think it doesn't. Because then you are obviously considering adding one
>> procfs file into /proc/sys/net/core/ *for each* feature that is added into
>> the ancillary ops which cannot be the right way ...
>
> We had already brought up this topic previously in the same thread. A
> suggestion was made to add that proc entry and no one from netdev
> responded to it saying that it did not make any sense. Therefore
> before I went ahead and made the fixes in libpcap, I wanted to run
> this by your guys again to make sure we are still on the same page.
Well, not everyone on netdev might be following this thread (resp.
following fully). The best way to get responses for a patch is to go
through the normal patch submission process on netdev, and if you like
to request for comments, then mark it as RFC in the subject. This way,
people will know and likely comment on it if it makes sense or not.
> I do agree that instead of a /proc entry, we should check for a kenrel
> version >= X where X is the upstream version that first started
> supporting all the features needed by libpcap for vlan filtering. This
> is not a compile time check but a run time one. Does anyone see any
> issues with this? Is there any long term implications of this, like if
> you backport patches to an older long term supported kernel? Are there
> other better ways to do this, like may be returning feature bits from
> an ioctl call? This is something we need to deal with on a continuous
> basis as we keep supporting newer AUX fields and libpcap and other
> user land code needs to make use of it. At the same time, they need to
> handle backward compatibility issues with older kernels.
As Eric mentioned earlier, for now there seems not to be a reliable
way to get to know which ops are present and which not. It's not
really nice, but if you want to make use of those new (ANC*) features,
probably checking kernel version might be the only way if I'm not
missing something. Now net-next is closed, but if it reopens, I'll
submit a version 2 of my patch where you've been CC'd to. If it gets
in, then at least it's for sure that since kernel this kind of
feature test is present.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
On Thu, Dec 13, 2012 at 1:49 PM, Daniel Borkmann wrote: > Well, not everyone on netdev might be following this thread (resp. > following fully). The best way to get responses for a patch is to go > through the normal patch submission process on netdev, and if you like > to request for comments, then mark it as RFC in the subject. This way, > people will know and likely comment on it if it makes sense or not. OK good to know. > As Eric mentioned earlier, for now there seems not to be a reliable > way to get to know which ops are present and which not. It's not > really nice, but if you want to make use of those new (ANC*) features, > probably checking kernel version might be the only way if I'm not > missing something. Now net-next is closed, but if it reopens, I'll > submit a version 2 of my patch where you've been CC'd to. If it gets > in, then at least it's for sure that since kernel this kind of > feature test is present. thanks, yes, I believe we do need some sort of validation on the ancilliary features. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
