Dear Scott,
--------------------------------------------
From: Scott Robison <[email protected]>
Sent: Mon, 15 Dec 2014 13:25:53 -0700
To: [email protected]
Subject: Re: [fossil-dev] Fossil-scm.org SSL login mismatch
On Mon, Dec 15, 2014 at 11:58 AM, jungle Boogie <[email protected]>
wrote:
But then why doesn't the fossil project support sslv1? Backwards
comparability is important but when there are vulnerabilities within
the application, those shouldn't be carried over to new versions, imo.
One, because sslv1 was never released. From Wikipedia (
http://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0.2C_2.0_and_3.0):
"The SSL protocol was originally developed by Netscape
<http://en.wikipedia.org/wiki/Netscape_Communications_Corporation>.[9]
<http://en.wikipedia.org/wiki/Transport_Layer_Security#cite_note-9> Version
1.0 was never publicly released because of serious security flaws in the
protocol; version 2.0 was released in February 1995 but "contained a number
of security flaws which ultimately led to the design of SSL version 3.0".
[10] <http://en.wikipedia.org/wiki/Transport_Layer_Security#cite_note-10>"
So v1 was never released publicly, so no need to continue to support it.
Okay, you caught me--I didn't actually look up sslv1. Thanks for the
information, though. It's probably BETTER v1 was never released or else we'd
still have 'clients' that depend on it and no one would be willing to disable
it. ;)
Two, I'm not advocating one way or the other, just stating that it is
conceivable that it might be useful by someone out there and that forcibly
disabling it in fossil *might* be negatively impact someone somewhere.
Which is not a reason to live with the status quo, just something to
contemplate.
Security is a trade off between usability and security. If your
product/project is so secure no one can use it, that won't do any good, but if
your product/project is vulnerable where the data can be modified unwillingly
to you, then that's also an issue. The intent with SSL and later TLS is to
encrypt to connection between the server and client, we know this, but if that
encryption can be modified or monitored midstream, why bother with the
encryption?
That being said, my original comment still stands: If it is removed from
the
SSL library when it is built, it can't be used by fossil *or any other
dependent piece of software*. Surely that is a more efficient solution,
removing it once from the library rather than researching all software
that
might use SSL and making sure they've all been updated to remove support
for
obsolete functionality. Just a thought.
This is absolutely correct.
My operating system of choice is freeBSD and I mostly use packages
(pre-compiled programs). OpenSSL has the sslv2 and sslv3 enabled in
the ports so that means unless someone compiles openssl, the default
action is to enable SSL v2 and sslv3. I've been in discussion with the
freebsd ports security group to have sslv2/3 disabled but there is
much resistance at this point, maybe within the next couple versions
they'll be more willing.
My OS of choice is also FreeBSD, so good on you. :) I can only guess, but I
suspect their rationale is similar to mine. It would be nice at least if
they were to provide a simple knob to disable older insecure protocols, but
that's easy for me to say since I'm not the one in charge of maintaining it.
Yes, some config option in fossil would solve all issues. Default v2 & v3 it
to off, of course ;).
Best,
Jungle
--
inum: 883510009027723
sip: [email protected]
xmpp: [email protected]
_______________________________________________
fossil-dev mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/fossil-dev
