Hello and thank you for stunnel! After switching from my web-server's built-in SSL support, I now have a much more secure system and SNI, too!

In stunnel(8), I read this about the sni option:

"sni option can also be specified more than once within a single slave service."

However, I couldn't get it to work, and reading the source code verified that only one sni option is tracked per section.

So, I present my patch to allow multiple sni options. It enables configurations like these:

[https] ...

[group1] sni = https:a.example.org sni = https:b.example.org ...

[group2] sni = https:c.example.org sni = https:d.example.org ...

If you have a naming scheme that doesn't lend itself to the wildcard matching already supported, this can cut your config size quite a bit.

DETAILS

The sni option for any section was originally tracked in the section->sni member (a string). Now, a linked-list of sni options is added to the section structure, with every sni option being appended to the end.

For server setup, each slave section walks over its list, splitting each sni option and adding that slave section to the master's slave list. Splitting options and adding slaves to masters works as before, but now the slave section iterates over a list instead of referencing a single string.

For client setup, each slave section checks that it has either no sni options, or exactly one. Multiple sni options results in an error. If exactly one option is found, it is copied to the old sni field of the section struct. The old sni field has been renamed to servername_to_request, as it is now used only in client mode, and this makes its purpose more clear. When no sni option is found, servername_to_request is initialized from the protocolHost or connect options, as before.

I hope this patch is useful to others. Please let me know how I can make it acceptable for inclusing in the stunnel distribution.

Thanks, David