blob: cca881455f497e0aee7e2ba61481b12673859b34 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
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."
|
