supporting ssl/tls-enabled services not apparently supported

[baallan]

I'm interested in supporting https, imaps, secure pop3, and so forth in honeyd. Is there a good technical reason I'm overlooking that this cannot be done , or is it known to be a mere matter of coding it up? If it's a mere matter of code, would a patch adding this feature have any chance of being accepted, or must such core work be done by datasoft?

And, yes, I've looked at some other honey pot tools which already support ssl-enabled protocols, but for various reasons honeyd became the 1st choice for the particular application.

[altf4]

As to code patches, the answer is that we welcome patches from anyone! We'd take it in whatever format is most convenient to you. A patch file, github pull request, out-of-band pull request, code written on paper towels in crayon, anything.

As for SSL support... that's more interesting. The implementation would have to be inside honeyd itself. Since implementing it in the scripts would be horribly slow and also suffer from a lack of agreement about language. (Since the scripts can run as any language)

Honeyd would have to keep track of what ports are using TLS and which aren't. And then when data is received on that port, decrypt it and pass that through to the script. Similarly, when data is sent from a script through honeyd, it would have to encrypt up the data before sending off. Honeyd is kind of a man-in-the-middle for the actual recipient (the script) who wouldn't even know if it was TLS or not.

There's some logistical issues. Like managing the TLS certificates, which may be annoying. But that could get sorted out.

[baallan]

I've been perusing the honeyd source today trying to figure out what's where (I'm new to honeyd, but not new to C) and how I might go about: a) adding some new config option that indicates a port be handled with TLS b) finding the best place to put all the ssl bits, as illustrated in IBMs 'server application with ssl code' http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=%2Fcom.ibm.ztpf-ztpfdf.doc_put.cur%2Fgtps5%2Fs5examp.html

I'm pretty sure I can figure out (a). If anyone more expert in the current code wants to take a swing at providing some guidance for (b), that would be fabulous. It does seem like it's reasonable in principle...

[altf4]

In fact, the TLS part might not be all that hard. Honeyd already uses libevent for all its network operations. And libevent has OpenSSL support. It might not be much harder than turning SSL on, and managing certificates.

The hairy problem might be the cert managing. How do you know what cert goes to what honeypot / port? You don't want to reuse the same cert. Do you leave cert generation completely up to the user?

[PherricOxide]

Some random tips for (a)

Honeyd uses yacc/lex for parsing it's configuration file.

The lex stuff is defined in lex.l The yacc stuff is defined in parse.y

lex.c, parse.c, and parse.h are all auto generated. To regenerate them after editing lex.l and parse.y, just delete them and rebuild,

make clean
rm lex.c parse.h parse.c
make

I'm thinking the configuration file would have something like,

add profileFoo tcp ssl port 80 "tclsh /usr/share/honeyd/scripts/linux/httpd/httpd.tcl"

Instead of what it currently would be,

add profileFoo tcp port 80 "tclsh /usr/share/honeyd/scripts/linux/httpd/httpd.tcl"

Then you'd have to have some way to specify what SSL cert to use for that port too.

I'd worry about the SSL (b) part of the problem more than (a) though, you could just hard code some SSL cert and try to stuff everything through SSL temporarily to get a prototype going.

As for (b), honeyd is pretty low level. It can't use OS sockets (which your example is binding to), because a good part of what honeyd does is have the ability to mimic different TCP/IP fingerprints by creating all it's packets from scratch. It just monitors promiscuously on the interface with pcap and parses all the packets by itself, keeping track of "connections" and whatnot internally.

Packets come in through,

 Stuff in interface.c starts pcap captures on all of the interfaces
 All the packets honeyd sees get sent to the pcap callback function honeyd.c:honeyd_recv_cb
 Honeyd has the ability to routes and delay packets (emulating a slow link), and it does so after honeyd_input
 Eventually honeyd.c:honeyd_dispatch will figure out if it's a TCP, UDP, or ICMP packet and give it to the proper callback handler

Packets go out... well, I think mainly through honeyd_ip_send? It would take some research to figure out.

You're going to have raw packets going in and out though, can that be passed to openSSL somehow? Can you emulate a socket openSSL can use? I don't know, needs some research.

[worldwise001]

You may also want to consider that some daemons use STARTTLS (http://en.wikipedia.org/wiki/STARTTLS) which adds TLS/SSL to plaintext communication protocols. I know for a fact that exim allows this, at least on ports 25 and 587. I'm not sure how well this would be supported, unless it was entirely done script-side (as in, an application profile would handle it, not honeyd itself).

Also, in some cases (at least I know of this in SSH), as part of the secure protocol negotiation, both parties exchange what crypto libraries they have available, so this could be another factor when implementing TLS/SSL capability into honeyd.

[PherricOxide]

Yeah, maybe there could be some way for the scripts/services to tell honeyd to "activate" ssl mode? That's part of a bigger problem we haven't fixed yet of how can the scripts communicate with honeyd more commands and information than the basic stdin/stdout conversion to packets.

[altf4]

PherricOxide is right that honeyd doesn't talk over sockets like a normal network program does. After all, it has to pretend to be lots of machines that don't exist. If you sent a packet using the normal socket libraries, it would have the wrong addresses on the packet, and such.

Honeyd uses libdumbnet to send out raw data packet by packet. So libevent is not an option (it's not even used for socket IO here) and so are any other SSL libraries that operate on a socket itself. It would have to operate on a simple buffer... but then how you handle all the complicated mess of SSL options like cipher negotiations, mid-stream re-negotiations, clean teardowns, etc... I'm not sure how all that would work.

[baallan]

This now sounds like it ends up in a fairly complete reimplementation of a TLS library into honeyd to support https. I suspect that's not a good idea from a security/maintenance perspective. A prototype might make an interesting honeynet gsoc project, however. The starttls angle might be workable for some of the other protocols; will need to dig more when those protocols rise to the top of the requirements stack. Thanks to all for the very timely input.

[altf4]

So there may be a ray of hope here. libevent can operate on files. And so we might be able to enable TLS by redirecting all the traffic through a file. So it would look like:

Input: Libpcap get raw bytes -> Written to file -> Read by libevent TLS decrypted -> honeyd service script

Output: honeyd script -> libevent TLS encrypt -> write to file -> ? -> write to wire via libdumbnet

The ? might have to be a daemon or something which listens on that file(s). It's a little kludgey... but better than reimplementing TLS by hand.

[baallan]

Work has now taken me far away from this. If it's of interest to anyone else, they should reopen it.