mirror of
https://github.com/nmap/nmap.git
synced 2025-12-06 04:31:29 +00:00
42 lines
2.4 KiB
Plaintext
42 lines
2.4 KiB
Plaintext
o Proper SSL support in proxy mode.
|
|
- A naive implementation relying on the current code would probably look
|
|
horrible (at least my own attempts did). I believe that nsock should
|
|
internally be able to SSLify a plain TCP connection. It doesn't have to be
|
|
exported but it should be implemented just like the other operations. Then
|
|
it would be trivial (and clean) for the library to SSLify the channel
|
|
established by the proxy hooks.
|
|
- When redesigning nsock SSL code, keep in mind the ability to establish a SSL
|
|
session and still expose the raw TCP. That can be convenient when auditing
|
|
the SSL/TLS layer.
|
|
o Don't drop pending writes when deleting the corresponding IOD. For nsock to
|
|
behave a bit like standard BSD sockets we should flush writes on close. (OTOH
|
|
anything which isn't ack'ed has no meaning, caller can still cancel it
|
|
typically...)
|
|
o Give IODs their own methods to streamline the code and get rid of all
|
|
the special cases in nsock_core.c. This would also make it easier to
|
|
hook operations (typically: override the default iod_connect() method
|
|
to establish a proxy chain).
|
|
o Fix the read API (!)
|
|
o Profile the pcap code. It needs cleanup (for sure) and optimizations (maybe).
|
|
o Proxy authentication
|
|
o Handle socks4a
|
|
- This requires to figure out how to trigger proxy code without
|
|
resolving target hostname first. The problem is that the proxy code
|
|
is supposed to be a transparent hook of connect()... Extending the
|
|
exported API will probably be needed :(
|
|
- Async hostname resolution available from within nsock would let us
|
|
try clever tricks... I'm not sure whether nsock should provide it
|
|
or if it should simply provide an API to plug an external system.
|
|
o Socks5 support
|
|
o Some code is copied from ncat. I should move it to nbase.
|
|
o Replace event lists by more efficient data structures. Consider using
|
|
a radix tree to map event IDs to pointers. Another solution would
|
|
be to put them all into a single RB-tree (TODO: validate BSD_HACK_MODE
|
|
& stuff). Encoding the event type in the ID's MSB would let us do inorder
|
|
traversal with connect events first, then read, then write...
|
|
{NOTE: It'd be cool for the beauty of it, but my tests reveal that as of Oct.
|
|
2013 there's no big bottleneck there.}
|
|
o Rework the filespace code to avoid unneeded data copy. Scatter/gather
|
|
I/O might be useful there. Same task can also be expressed as: "profile and
|
|
optimize the usual nmap nsock I/O patterns."
|