> Even the examples given in the IO::Socket::SSL's examples directory were hard to use, the use of GetOpt long obfuscated the script to make it look like mangled javascript. :-)

The use of the verbose GetOpt::Long instead of Getopt:Std and the extensive usage description are actually intended to make the code more easy to understand. I'm not sure why you see this as obfuscated code but I'm open for improvements.

> First, you need to use an IO::Socket::SSL::SSL_Context object to start_SSL on client sockets as they are accepted.

There is no inherent need to explicitly provide a context since it is implicitly created if you don't provide an explicit one. But it is recommend to provide a separate context if you want to use the same context for multiple servers or multiple client connections.

> ... you cannot use a READLINE or variant to read and write the sockets. The SSL sockets are sent in frames of 16k (iirc), and newlines are meaningless in encrypted transfers. So use sysread and syswrite.

This is wrong. getline, <$fh> will still work and even using a different $/ ($INPUT_RECORD_SEPARATOR) will work. Newlines have the same meaning as with a simple TCP socket, i.e. they are just data and there is no special way of transferring these data. And while the data in TLS are sent in frames of up to 16k this is irrelevant if you deal with blocking sockets only but it can be important if you deal with non-blocking sockets and select: either always try to sysread at least 16k or deal with buffered data by using the pending function.

> Third, using select with the accepted clients can be tricky. Fortunately, Gtk2 handles it's socket callbacks with great detail, and it works.

The tricky part is to use select with non-blocking sockets. You don't use any non-blocking sockets and so it looks like it will work. Once you use non-blocking socket you will see that it does not work properly as currently done. There is no special magic done by Gtk2 which would help here. Since your code is not using non-blocking sockets a simple TCP connect without following SSL handshake to your server will cause your program to stall since your server is trying to do the SSL handshake in a blocking way.

> Fourth, self-generated certificates and keys will work, but with SSL_verify_mode => 0. This makes it susceptible to man in the middle attacks because you have no way to verify the keys. But it is about the only way to get the encryption going without a real Certificate of Authority.

First, it is possible to be your own CA, i.e. have your own root CA and issue your own certificates. This CA then can be set as trusted with SSL_ca_file or similar. Then, it is possible to use your own certificates in a secure way (i.e. no MITM) even if these are self-signed. Have a look at the SSL_fingerprint option in the documentation.