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
