2:32 a.m.
Hi all,
I'm sure you're all aware of the recent security flaws exposed with SSL3.
Therefore I have to ask, should we disable SSL2 and SSL3 support in ssl.el?
A little bit of reading shows that we can probably do this by adding
-no_ssl2 and -no_ssl3 to the ssl-program-arguments in ssl.el. I have
not tested it yet.
Are there other SSL interfaces exposed on the lisp level?
Johann
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:11 a.m.
On Fri, 21 Nov 2014 02:32:42 +0000
"Johann 'Myrkraverk' Oskarsson"
<myrkraverk(a)users.sourceforge.net>
wrote:
Hi all,
I'm sure you're all aware of the recent security flaws exposed with
SSL3.
Therefore I have to ask, should we disable SSL2 and SSL3 support in
ssl.el?
A little bit of reading shows that we can probably do this by adding
-no_ssl2 and -no_ssl3 to the ssl-program-arguments in ssl.el. I have
not tested it yet.
Are there other SSL interfaces exposed on the lisp level?
Disabling ssl2 is probably a good idea. It is very obsolete now and (I
assume) somebody who really needs it can enable it.
ssl3 is a bit more iffy. IMHO the poodle attack is overblown since the
attacker also needs a man in the middle attack. It also looks like they
need a connection for every byte which is easy to look for and rate
limit with any good firewall.
On the other hand, most clients support TLS now. So if it is easy to
re-enable it I don't see a huge problem.
In short, if it is easy to re-enable them then my gut reaction is that
disabling them would be a good idea.
Cheers,
Sean
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:46 a.m.
Hi Sean, xemacs-beta,
On Fri, Nov 21, 2014 at 5:11 AM, Sean MacLennan <seanm(a)seanm.ca> wrote:
On Fri, 21 Nov 2014 02:32:42 +0000
"Johann 'Myrkraverk' Oskarsson"
<myrkraverk(a)users.sourceforge.net>
wrote:
> Therefore I have to ask, should we disable SSL2 and SSL3 support
in
> ssl.el?
In short, if it is easy to re-enable them then my gut reaction is
that
disabling them would be a good idea.
Is M-x customize-variable RET ssl-program-arguments RET easy enough?
Again, I've not tested these arguments, only looked in the man page.
Johann
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:12 p.m.
On Fri, 21 Nov 2014 10:46:20 +0000
"Johann 'Myrkraverk' Oskarsson"
<myrkraverk(a)users.sourceforge.net>
wrote:
Hi Sean, xemacs-beta,
On Fri, Nov 21, 2014 at 5:11 AM, Sean MacLennan <seanm(a)seanm.ca>
wrote:
> On Fri, 21 Nov 2014 02:32:42 +0000
> "Johann 'Myrkraverk' Oskarsson"
<myrkraverk(a)users.sourceforge.net>
> wrote:
>> Therefore I have to ask, should we disable SSL2 and SSL3 support in
>> ssl.el?
> In short, if it is easy to re-enable them then my gut reaction is
> that disabling them would be a good idea.
Is M-x customize-variable RET ssl-program-arguments RET easy enough?
Again, I've not tested these arguments, only looked in the man page.
Good enough for me!
Cheers,
Sean
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:03 a.m.
Johann 'Myrkraverk' Oskarsson writes:
I'm sure you're all aware of the recent security flaws
exposed with SSL3.
Therefore I have to ask, should we disable SSL2 and SSL3 support in ssl.el?
There's a long thread on this issue on emacs-devel. It was
inconclusive, there are security hawks and doves. larsi and tzz are
busily creating a "network security manager" nsm, though I'm not
terribly impressed with their understanding of security.
My own opinion is that any security measure that interrupts the user's
browsing likely to get disabled, and we really should find better ways
to address these issues.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:57 a.m.
Hi Stephen, xemacs-beta,
On Sat, Nov 22, 2014 at 6:03 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Johann 'Myrkraverk' Oskarsson writes:
> I'm sure you're all aware of the recent security flaws exposed with SSL3.
>
> Therefore I have to ask, should we disable SSL2 and SSL3 support in ssl.el?
My own opinion is that any security measure that interrupts the
user's
browsing likely to get disabled, and we really should find better ways
to address these issues.
Then why don't you make an informed decision?
In Chrome, SSL3 will be disabled in version 39, and gone completely in
40, according to this:
https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/Vnhy9...
Firefox will disable SSL3 by default starting with version 34; see
https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-en...
Apple released security update to Safari; see
http://support.apple.com/en-us/HT203107
Opera as of version 25 has countermeasures; see
http://blogs.opera.com/security/2014/10/security-changes-opera-25-poodle-...
Some websites that already don't speak ssl3:
www.microsoft.com
www.apple.com
www.hp.com
And neither does my bank.
SSL3 is almost 18 years old, and the world is moving on. Why do you
want to hold ssl.el back?
In the end, I really don't care if you want a patch or not; I can do
this for myself.
Johann
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:31 p.m.
Johann 'Myrkraverk' Oskarsson writes:
Then why don't you make an informed decision?
In Chrome, SSL3 will be disabled in version 39, and gone completely
in 40, according to this:
*sigh* What the big browsers do in their bleeding edge version is not
the relevant information. What matters is what is happening where our
users live, and there is some evidence (eg, the discussions on
Python-Dev) that many corporations' intranets remain a big mess[1],
and those are precisely the places that are conservative about
upgrading things like browsers. Perhaps they would be equally
conservative about upgrading Emacsen, but the folks I know who have
worked in those environments think that Emacsen tend to get upgraded
somewhat faster because the users are more sophisticated and/or have
more power over what's installed on their machines.
Some websites that already don't speak ssl3:
www.microsoft.com
www.apple.com
www.hp.com
And neither does my bank.
Again, not really the interesting information. What is interesting is
which sites still speak only obsolete versions of SSL and versions of
TLS that are considered vulnerable, and whether our users need to
access those sites.
SSL3 is almost 18 years old, and the world is moving on. Why do you
want to hold ssl.el back?
I don't want to hold anything back. I want to avoid screwing our
users by removing support for something that (they think) they need.
I don't care if the default is to not support those protocols, but a
minimum level of support for XEmacs is a `supported-tls-protocols'
variable (name is up for grabs, of course) which has a choice
customization widget providing the obsolete protocols as options
(along with a warning as big and red as you like in the doc for each
option).
Footnotes:
[1] Including some like Google!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:05 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
I don't want to hold anything back. I want to avoid screwing
our
users by removing support for something that (they think) they need.
At the same time we would want to help the users do informed decisions
so that they not by mistake use not secure protocols. So it is a
tradeoff.
I don't care if the default is to not support those protocols,
but a
minimum level of support for XEmacs is a `supported-tls-protocols'
variable (name is up for grabs, of course) which has a choice
customization widget providing the obsolete protocols as options
(along with a warning as big and red as you like in the doc for each
option).
So setting the default to TLS 1.0 and at the same time document how to
customize that to lower levels seems reasonable too me. And in the
cases where it is implemented with openssl I guess the user is anyway
at the mercy of that implementation.
However we also have the problem that not all encrypted traffic passes
through ssl.el. So we would have to see to so that
supported-tls-protocols is respected by all places where encrypted
traffic takes place.
You see, triggered by this thread, I noticed that gnus uses openssl
directly and, as it seems, could even try to use sslv2 in case that
sslv3 does not work. That does not sound good.
I have also been ignorant and not been looking into the tls-support
recently added to the core. So I don't know if that is applicable here
but from the name is sounds like we should start using that and only
fall back to ssl, and other implementations (openssl!?), if the user
requests it!?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:06 a.m.
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> I don't want to hold anything back. I want to avoid screwing our
> users by removing support for something that (they think) they need.
At the same time we would want to help the users do informed decisions
so that they not by mistake use not secure protocols. So it is a
tradeoff.
As I say, I don't care about the default. Default off, let people who
know why they need it opt in.
BTW, informed decisions are nice, but the human factors research with
respect to security is very discouraging. For 90% of users-off-the-
street (which admittedly is not likely to be representative of XEmacs
users), the cost of two keystrokes beats risking having your bank
account emptied. Specifically, most users are completely unaware of
the difference between http: and https: URLS (which, believe it or
not, is apparently *made worse* by the practice of some browsers of
displaying the scheme "https://" but not the scheme "http://"), and
do
not know how to interpret the little lock symbol. That means that if
SSL2/3 are not available, 90% of users will happily fall back to
unencrypted connections to get their work done. :-(
Bottom line: disabling buggy encryption protocols is not a no-brainer.
These days I'd say the odds strongly favor defaulting SSL2/3 *off*.
I'm not ready to remove them, though. TLS 1.0[1] has some known
issues, too, but I don't think we can default that off yet.
However we also have the problem that not all encrypted traffic
passes
through ssl.el. So we would have to see to so that
supported-tls-protocols is respected by all places where encrypted
traffic takes place.
I think if you're that worried about security, you shouldn't being
using Emacsen at all. Half-joking, of course, but really, if there's
real insecurity in your system, Emacs use is a crack waiting to
happen. Are all your elisp files secure? Are you *sure*? Do you
have a list of SHA1s on readonly material, and verify your elcs
against them whenever you load?
I have also been ignorant and not been looking into the tls-support
recently added to the core. So I don't know if that is applicable here
but from the name is sounds like we should start using that and only
fall back to ssl, and other implementations (openssl!?), if the user
requests it!?
The core support *is* OpenSSL (or nss or gnutls), and they all support
the older protocols. The problem with OpenSSL is that in the 0.9.x
series, which is still prevalent on many platforms, the default at the
library level is to fall all the way back to SSL2. I'm not even sure
when TLS 1.0 support was added; Mac OS X Tiger and Leopard (maybe even
Snow Leopard) may not even *have* proper TLS support. OTOH, OpenSSL
1.01j is state-of-the-art in this respect (including the fix for
HeartBleed).
OTOH, AFAIK none of the packages we can use refuse to make a
connection if they can't verify the signature back to a known root
certificate. Anybody can self-sign, so spoofing via cousin domains
(YourBank.com.my, anyone?) is trivial.
Footnotes:
[1] IIRC. I'm sure I recall somebody on Python-Dev advocating
disabling one of the TLS versions.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:14 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
These days I'd say the odds strongly favor defaulting SSL2/3
*off*.
I'm not ready to remove them, though. TLS 1.0[1] has some known
issues, too, but I don't think we can default that off yet.
This sounds good to me.
I think if you're that worried about security, you shouldn't
being
using Emacsen at all. Half-joking, of course, but really, if
there's real insecurity in your system, [...]
This is not about the security of our machines. It is about securing
the traffic going in and out.
The core support *is* OpenSSL (or nss or gnutls), and they all
support the older protocols. [...]
What I mean is that, at least when it comes to GNUS, it uses the
openssl client through some process interface. I
guessed/thought/dreamed our tls-module would provide some API instead
(which might use the openssl client below the surface for what I know)
and that we should use that in gnus, ssl.el and whatever other places
we use tls/ssl. I haven't looked at it though more than I know we now
have a file called tls.c.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:14 a.m.
Mats Lidell writes:
> I think if you're that worried about security, you
shouldn't being
> using Emacsen at all. Half-joking, of course, but really, if
> there's real insecurity in your system, [...]
This is not about the security of our machines. It is about securing
the traffic going in and out.
There's no real difference. Most exploits happen at endpoints, not by
cracking streams en route. SSL2 is good enough to prevent casual
eavesdropping. If somebody *wants* to steal your information, I don't
think they'll stop trying just because your transport security is the
latest and greatest.
> The core support *is* OpenSSL (or nss or gnutls), and they all
> support the older protocols. [...]
What I mean is that, at least when it comes to GNUS, it uses the
openssl client through some process interface.
Yes, I understand that. My point is that basically, because this is
system security, if you decide to disable a protocol, you want to do
it system-wide rather than one app at a time. Similarly, if a new
stronger protocol is developed, you'd like your TLS library to provide
it to all apps without rebuilding the apps if possible, and surely
without changing their source code. Thus, that client is just a thin
layer (command line parser, basically) over the library which provides
the defaults -- that's the only way you can get such system-wide
behavior.
If some app or use case really needs it, that app can change the
protocols in use explicitly. I don't see that Emacsen have special
needs here. But some users may, thus the need for configurability.
I guessed/thought/dreamed our tls-module would provide some API
instead (which might use the openssl client below the surface for
what I know) and that we should use that in gnus, ssl.el and
whatever other places we use tls/ssl. I haven't looked at it though
more than I know we now have a file called tls.c.
It does provide such an API, but it's not clear to me that the new API
provides all that many advantages over the existing use of a TLS
helper process. I don't think it's worth the effort to rewrite
existing programs. Let the Emacs guys do that. ;-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:05 p.m.
Hi Stephen, xemacs-beta,
On Sun, Nov 23, 2014 at 2:31 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Johann 'Myrkraverk' Oskarsson writes:
Again, not really the interesting information. What is interesting
is
which sites still speak only obsolete versions of SSL and versions of
TLS that are considered vulnerable, and whether our users need to
access those sites.
> SSL3 is almost 18 years old, and the world is moving on. Why do you
> want to hold ssl.el back?
I don't want to hold anything back. I want to avoid screwing our
users by removing support for something that (they think) they need.
So, how does changing ssl.el screw our users? For completeness, I did
the following experiment:
1) Configure a web server to server only ssl3.
2) Visit the site with emacs-w3m.
3) Customize ssl-program-argumens and add -no_ssl2 and -no_ss3.
4) Visit the site with emacs-w3m.
Bottom line, emacs-w3m does not use ssl.el. What browser uses it?
w3? That's officially been defunct since 2003. eww? Does that even
work in xemacs?
I don't care if the default is to not support those protocols,
but a
minimum level of support for XEmacs is a `supported-tls-protocols'
variable (name is up for grabs, of course) which has a choice
customization widget providing the obsolete protocols as options
(along with a warning as big and red as you like in the doc for each
option).
That's sort of reasonable, but who is going to do that?
In the mean time, adding -no_ssl2 and -no_ss3 as defaults is trivial
and protects the regular Joe who uses, say, erc.
Johann
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:35 a.m.
>>>> "Johann" == Johann Oskarsson <Johann>
writes:
Bottom line, emacs-w3m does not use ssl.el. What browser uses it?
w3?
ssl.el is part of the w3 package so I guess that is it!
And we don't have w3m in the packages. It has been on my,
maybe-I-should-add-that-to-the-packages list for a decade or so but I
haven't done it yet.
[About w3] That's officially been defunct since 2003. eww? Does
that
even work in xemacs?
Well I have never got it to work very well for me but is it officially
deprecated?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:47 a.m.
Hi Mats,
On Sun, Nov 30, 2014 at 12:35 AM, Mats Lidell <matsl(a)xemacs.org> wrote:
>>>>> "Johann" == Johann Oskarsson
<Johann> writes:
> [About w3] That's officially been defunct since 2003. eww?
Does that
> even work in xemacs?
Well I have never got it to work very well for me but is it officially
deprecated?
I thought it was; I'm sure I did not dream the number 2003, but now I
can't remember where I saw it.
According to
http://elpa.gnu.org/packages/w3.html
there was a release in 2013, and the emacswiki says development stalled in 2008.
http://www.emacswiki.org/emacs/w3
Johann
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:29 p.m.
>>>> Mats Lidell <matsl(a)xemacs.org> writes:
ssl.el is part of the w3 package so I guess that is it!
The ssl-support I use regularly is with imap and gnus and controlled
by the variable:
imap-ssl-program
Triggered by this discussion I customized it to this:
("openssl s_client -quiet -tls1_2 -connect %s:%p"
"openssl s_client -quiet -tls1_1 -connect %s:%p"
"openssl s_client -quiet -tls1 -connect %s:%p")
and my openssl connections are now using tlsv1.2 instead of sslv3 as
before!
So from imap.el we have
(defcustom imap-ssl-program '("openssl s_client -quiet -ssl3 -connect
%s:%p"
"openssl s_client -quiet -ssl2 -connect %s:%p"
"s_client -quiet -ssl3 -connect %s:%p"
"s_client -quiet -ssl2 -connect %s:%p")
...
I suggest that we change this to use tls only, probably just 1.2 and
1.1. Users that need sslv3 can always customize this.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:18 p.m.
Johann 'Myrkraverk' Oskarsson writes:
Bottom line, emacs-w3m does not use ssl.el. What browser uses it?
That's not my problem. If ssl.el starts with SSL2 and works up,
that's a major bug that needs to be fixed immediately, and just
disabling those protocols is a reasonable start.
If, as I expect, it starts with the most recent version of TLS and
works down, then it will hit SSL3 or SSL2 only in the (very rare,
according to you) event that the user is contacting a server that only
supports those obsolete protocols. Usually the user knows that they
need to contact such servers and why, although few users can make a
truly informed choice about whether the security risk is worth it.
Experience and HCI research say most will choose to force the
connection.
It is not our job to get in their way, and certainly not our job to
require them to write code to restore the capability. A customizable
variable is a minimal requirement here.
> I don't care if the default is to not support those
protocols, but a
> minimum level of support for XEmacs is a `supported-tls-protocols'
> variable (name is up for grabs, of course) which has a choice
> customization widget providing the obsolete protocols as options
> (along with a warning as big and red as you like in the doc for each
> option).
That's sort of reasonable, but who is going to do that?
You are, right? ;-) Look, you can write any patch you want for your
own modified version. But if you want it in the public distribution,
you need to consider the needs and likely behavior of the general
population of users. I see no reason to believe that we are likely to
save many users who might be vulnerable -- they'll just use a
different, more configurable app if they can't get XEmacs to do it.
We will, however, annoy and interfere with the work of *all* such
users who might be vulnerable: upgrading servers is nontrivial and
time-consuming at best, and most likely impossible for these users.
It's really not a lot of work to write a defcustom. Eventually I'll
do it -- disabling by default is the right thing to do -- but unless
you can get three reviewers to agree that a patch without the
defcustom is a good enough idea to override my veto, the disabling
patch itself will have to wait until somebody finds the time to write
the defcustom.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3402
days inactive
3442
days old
15 comments
4 participants
participants (4)
-
Johann 'Myrkraverk' Oskarsson -
Sean MacLennan -
Stephen J. Turnbull -
The XEmacs Package Smoketest