I used the protocol version from the record layer thinking I was using
the protocol version from the handshake. This commit fix this and uses
the protocol version from the handshake instead of from the record layer
as in https://gist.github.com/rcvalle/10335282, which is how it should
have been initially.
Thanks to @wvu-r7 for finding this out!
If encrypted, use the TLS_RSA_WITH_AES_128_CBC_SHA; otherwise, use the
first cipher suite sent by the client. This complements the last commit
and makes this module work with SSLv3, TLSv1.0, TLSv1.1, and TLSv1.2
when NEGOTIATE_TLS is not enabled (see
https://gist.github.com/rcvalle/10335282).
Use the protocol version sent by the client. This should be the latest
version supported by the client, which may also be the only acceptable.
This makes this module work with SSLv3, TLSv1.0, TLSv1.1, and TLSv1.2
when NEGOTIATE_TLS is not enabled (see
https://gist.github.com/rcvalle/10335282).
This does change some of the meaning of the required-ness of the
directories. Before, if you wanted to serve files, but not receive any,
you would just fail to set a OUTPUTPATH.
Now, since both are required, users are required to both send and
recieve. This seems okay, you can always just set two different
locations and point the one you don't want at /dev/null or something.
Otherwise you will tend to listen on your default ipv6 'any' address and
bound to udp6 port 69, assuming you haven't bothered to disable your
automatically-enabled ipv6 stack.
This is almost never correct.
* Allows responding to AAAA requests in addition to the existing A
support
* Prevents problems when recvfrom returns a mapped address like
"::ffff:192.0.2.1"
Also:
* Fix a few typos
* capture: Don't shadow a method name (arp) with a local variable
* capture: Handle the case where our UDP send hits an ENETUNREACH
Brings in neinwechter's BAP fixes. Seems to not only be a more sane
strategy, but in practice, ends up with tons more shells for at least
MSIE which is what most people are using it for anyway.
[Closes#1612]
In that order. #1476 was an attempt to salvage the functionality, but
sinn3r found some more bugs. So, undoing that, and undoing #1444 as
well.
First, do no harm. It's obvious we cannot be making sweeping changes in
libraries like this without a minimum of testing available. #1478 starts
to address that, by the way.
FixRM #7752