Re: [tcpdump-workers] Decoding the unencrypted part(s) of SSL/TLS?
On 12/11/2012 05:58 AM, Wesley Shields wrote: 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? The Client/Server Hellos are sufficient for my present purposes. 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. I've given it a quick try and it seems to be giving me what I need, though it may not be all that up-to-date on compression method id's. I did an apt-get so didn't have to build from source - though I may if I need to go-in and enhance its knowledge of ids. thanks all, rick jones ___ 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
>
> 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)
___
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, Dec 11, 2012 at 3:04 PM, Eric Dumazet wrote:
> 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.
yes I generated this patch wrong.
>
> Check lines 546, 547, 548 where we do the check for unknown instructions
>
> code = codes[code];
> if (!code)
> return -EINVAL;
yepph it's OK here.
>
> If you want to test ANCILLARY possible values, its already too late, as
> old kernels wont use any patch anyway.
yepph, I was looking at possible ancilliary values. Basically this
case statement :
#define ANCILLARY(CODE) case SKF_AD_OFF + SKF_AD_##CODE:\
code = BPF_S_ANC_##CODE;\
break
switch (ftest->k) {
ANCILLARY(PROTOCOL);
ANCILLARY(PKTTYPE);
ANCILLARY(IFINDEX);
ANCILLARY(NLATTR);
ANCILLARY(NLATTR_NEST);
ANCILLARY(MARK);
ANCILLARY(QUEUE);
ANCILLARY(HATYPE);
ANCILLARY(RXHASH);
ANCILLARY(CPU);
ANCILLARY(ALU_XOR_X);
ANCILLARY(VLAN_TAG);
ANCILLARY(VLAN_TAG_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 Tue, Dec 11, 2012 at 3:04 PM, Eric Dumazet wrote: > 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 > If you want to test ANCILLARY possible values, its already too late, as > old kernels wont use any patch anyway. > So basically this means that if we generate a filter with these special negative offset values and expect that the kernel will complain if it does not recognize the newer values then we would be wrong. And you are right. Old kernels never knew about them and the code wasn't written in a way to return EINVAL if it didn't recognize a special negative anciliary offset value. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
