[bincimap] Re: TLS using stunnel etc (was Re: relay control with binc)

[Dale Woolridge]

On 10-Mar-2003 12:54 Charlie Brady wrote:
| 
| That's probably very similar to this:
| 
| http://www.superscript.com/ucspi-ssl/install.html

    Only insofar as they want to provide (nearly) the same functionality.
    It's certainly much easier to scrutinize the patch.

| The problem with both options (for me at least) is that there are
| licensing problems. There is already enough confustion about Dan

    Sure, but the licensing problems don't affect bincimap.  There
    are many ways to get tls/ssl over tcp, without bincimap needing
    to know about it.

| >     I think this is better than STARTTLS as most clients don't offer enough
| >     choice to avoid potential man-in-the-middle attacks.
| 
| I don't understand why you think STARTTLS is any different to an SSLized 
| tcpserver in that respect.

    I was referring to clients which _prefer_ tls/ssl (via STARTTLS) over
    non-ssl dedicated channels, but which revert to non-tls/ssl when STARTTLS
    isn't advertised as a capability; they often do so without alerting
    the user.

| Sure, but that's a separate, and easier, issue. Using a wrapper such as 
| stunnel is simple in those cases.

    Absolutely.  I see now that you're actually interested in having STARTTLS
    supported, just not in bincimap, preferring a post-auth bincimap and
    some other layer to provide STARTTLS, like imap-auth or some such thing.
    Until clients get smarter, I think STARTTLS is a bad thing; sticking to
    respective ports is more reliable.
    
    On the other hand, bincimap at least has the option of disallowing plain
    auth without tls/ssl.  As far as I can tell, it won't be able to do
    that unless you put something else in the chain to give it the hint.
--
-dale