Countdown to SSL for all sessions?

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Countdown to SSL for all sessions?

Brion Vibber-4
Just curious -- what's the state of forcing HTTPS for all user sessions?
It's simple common sense at this point to protect all our users from
session hijacking on local networks or MITM attacks.

I see some Gerrit activity on adding "preferences" or special groups for
HTTPS, which seems a horrid practice when we could just protect everyone...

-- brion
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

James Forrester-4
On 29 April 2013 09:12, Brion Vibber <[hidden email]> wrote:
> Just curious -- what's the state of forcing HTTPS for all user sessions?
> It's simple common sense at this point to protect all our users from
> session hijacking on local networks or MITM attacks.

Now a bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=47832 (how
did we not have one already?).

> I see some Gerrit activity on adding "preferences" or special groups for
> HTTPS, which seems a horrid practice when we could just protect everyone...

Agreed; this was a nice idea back in the day when SSL was expensive, but now…

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

[hidden email] | @jdforrester

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Chris Steipp
In reply to this post by Brion Vibber-4
On Mon, Apr 29, 2013 at 9:12 AM, Brion Vibber <[hidden email]> wrote:
> Just curious -- what's the state of forcing HTTPS for all user sessions?
> It's simple common sense at this point to protect all our users from
> session hijacking on local networks or MITM attacks.
>
> I see some Gerrit activity on adding "preferences" or special groups for
> HTTPS, which seems a horrid practice when we could just protect everyone...

A handful of people have made comments that they really want the
option to not use HTTPS. And in MediaWiki, some sites may still be
concerned about the performance.

So I think the question is in MediaWiki, do we want to support sites
that allow users to disable SSL after login (which is the current use
of $wgSecureLogin)? If not, we can alter the functionality to make it
force all logged in sessions to use SSL. If so, is that something the
WMF wants to enable
(https://bugzilla.wikimedia.org/show_bug.cgi?id=39380), or do we want
another flag ($wgReallySuperSecureLogin) that forces sessions into
SSL?

Personally, I think giving users safe defaults, but the option to
shoot themselves *often* is the most secure option, because most users
will use the secure defaults, and people who want another option will
go to great, ugly lengths to circumvent your feature. This is the
direction I've been working towards, but if there is strong support
for another option, I'm happy to adjust.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Steven Walling
On Mon, Apr 29, 2013 at 9:40 AM, Chris Steipp <[hidden email]> wrote:

> Personally, I think giving users safe defaults, but the option to
> shoot themselves *often* is the most secure option, because most users
> will use the secure defaults, and people who want another option will
> go to great, ugly lengths to circumvent your feature. This is the
> direction I've been working towards, but if there is strong support
> for another option, I'm happy to adjust.
>

I think is sane as well. You see similar patterns from products like Gmail,
which have a preference to not use HTTPS all the time.

In the meantime, the new login form from our team detects whether the user
is on the HTTPS connection, and embeds a link at the top of the form if
you're not. Hopefully this will encourage more people to use it.

Steven
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Tyler Romeo
In reply to this post by Chris Steipp
Some relevant info:

Here's the Gerrit change implementing the user preference -
https://gerrit.wikimedia.org/r/47089

Also, $wgSecureLogin was deployed once to WMF wikis, but apparently a bug
occurred that was not present on my test environment. Once we figure out
what the source of that issue is, at the very least we can take the first
step and have secure login.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | [hidden email]
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Chris Steipp
On Mon, Apr 29, 2013 at 9:55 AM, Tyler Romeo <[hidden email]> wrote:
> Some relevant info:
>
> Here's the Gerrit change implementing the user preference -
> https://gerrit.wikimedia.org/r/47089
>
> Also, $wgSecureLogin was deployed once to WMF wikis, but apparently a bug
> occurred that was not present on my test environment. Once we figure out
> what the source of that issue is, at the very least we can take the first
> step and have secure login.

Using $wgSecureLogin with CentralAuth, if a global account logged in
and unchecked the box to continue using SSL, then SUL didn't correctly
log them in. This has been fixed in some of the updates to SUL that
we're working on right now
(https://www.mediawiki.org/wiki/Auth_systems/SUL2).

> *-- *
> *Tyler Romeo*
> Stevens Institute of Technology, Class of 2015
> Major in Computer Science
> www.whizkidztech.com | [hidden email]
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Tyler Romeo
On Mon, Apr 29, 2013 at 12:59 PM, Chris Steipp <[hidden email]>wrote:

> Using $wgSecureLogin with CentralAuth, if a global account logged in
> and unchecked the box to continue using SSL, then SUL didn't correctly
> log them in. This has been fixed in some of the updates to SUL that
> we're working on right now
> (https://www.mediawiki.org/wiki/Auth_systems/SUL2).
>

Aha. I figured it had something to do with CentralAuth or another extension.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | [hidden email]
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Paul Selitskas
There are some situations when HTTPS won't work (for example, blocked
by provider or government). How does one disable HTTPS without
actually accessing a HTTPS version if the user is redirected from HTTP
automatically?

HTTPS was once blocked in Belarus, thus disabling access to above
mentioned GMail, Facebook, Twitter and so on. There should be always
an option (like ?noSecure=1).

On Mon, Apr 29, 2013 at 8:03 PM, Tyler Romeo <[hidden email]> wrote:

> On Mon, Apr 29, 2013 at 12:59 PM, Chris Steipp <[hidden email]>wrote:
>
>> Using $wgSecureLogin with CentralAuth, if a global account logged in
>> and unchecked the box to continue using SSL, then SUL didn't correctly
>> log them in. This has been fixed in some of the updates to SUL that
>> we're working on right now
>> (https://www.mediawiki.org/wiki/Auth_systems/SUL2).
>>
>
> Aha. I figured it had something to do with CentralAuth or another extension.
>
> *-- *
> *Tyler Romeo*
> Stevens Institute of Technology, Class of 2015
> Major in Computer Science
> www.whizkidztech.com | [hidden email]
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
З павагай,
Павел Селіцкас/Pavel Selitskas
Wizardist @ Wikimedia projects

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Tyler Romeo
On Mon, Apr 29, 2013 at 9:07 PM, Paul Selitskas <[hidden email]>wrote:

> There are some situations when HTTPS won't work (for example, blocked
> by provider or government). How does one disable HTTPS without
> actually accessing a HTTPS version if the user is redirected from HTTP
> automatically?
>
> HTTPS was once blocked in Belarus, thus disabling access to above
> mentioned GMail, Facebook, Twitter and so on. There should be always
> an option (like ?noSecure=1).
>

Well, with $wgSecureLogin the idea is that it is completely disallowed to
log in, i.e., enter a password, over an insecure connection.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | [hidden email]
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Paul Selitskas
On Tue, Apr 30, 2013 at 5:55 AM, Tyler Romeo <[hidden email]> wrote:

> On Mon, Apr 29, 2013 at 9:07 PM, Paul Selitskas <[hidden email]>wrote:
>
>> There are some situations when HTTPS won't work (for example, blocked
>> by provider or government). How does one disable HTTPS without
>> actually accessing a HTTPS version if the user is redirected from HTTP
>> automatically?
>>
>> HTTPS was once blocked in Belarus, thus disabling access to above
>> mentioned GMail, Facebook, Twitter and so on. There should be always
>> an option (like ?noSecure=1).
>>
>
> Well, with $wgSecureLogin the idea is that it is completely disallowed to
> log in, i.e., enter a password, over an insecure connection.
>

Ah, I missed that moment. Thanks.

--
З павагай,
Павел Селіцкас/Pavel Selitskas
Wizardist @ Wikimedia projects

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Petr Bena
SSL is requiring more CPU, both on server and client and disable all
kinds of cache (such as squid or varnish), and some browsers may have
problems with it OR in some countries encryption may be even illegal.

Whatever you are going to do, you should let people turn it off.
Wikimedia project itself has horrible security (in this thread I
started some time ago -
http://www.gossamer-threads.com/lists/wiki/wikitech/277357?do=post_view_threaded#277357
I was even told that wikimedia doesn't need good security at all,
because user accounts aren't so critical there), forcing SSL will not
improve it much

On Tue, Apr 30, 2013 at 6:30 AM, Paul Selitskas <[hidden email]> wrote:

> On Tue, Apr 30, 2013 at 5:55 AM, Tyler Romeo <[hidden email]> wrote:
>> On Mon, Apr 29, 2013 at 9:07 PM, Paul Selitskas <[hidden email]>wrote:
>>
>>> There are some situations when HTTPS won't work (for example, blocked
>>> by provider or government). How does one disable HTTPS without
>>> actually accessing a HTTPS version if the user is redirected from HTTP
>>> automatically?
>>>
>>> HTTPS was once blocked in Belarus, thus disabling access to above
>>> mentioned GMail, Facebook, Twitter and so on. There should be always
>>> an option (like ?noSecure=1).
>>>
>>
>> Well, with $wgSecureLogin the idea is that it is completely disallowed to
>> log in, i.e., enter a password, over an insecure connection.
>>
>
> Ah, I missed that moment. Thanks.
>
> --
> З павагай,
> Павел Селіцкас/Pavel Selitskas
> Wizardist @ Wikimedia projects
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Happy Melon-2
On 30 April 2013 18:27, Petr Bena <[hidden email]> wrote:

> SSL is requiring more CPU, both on server and client and disable all
> kinds of cache (such as squid or varnish), and some browsers may have
> problems with it OR in some countries encryption may be even illegal.
>
> Whatever you are going to do, you should let people turn it off.
> Wikimedia project itself has horrible security (in this thread I
> started some time ago -
>
> http://www.gossamer-threads.com/lists/wiki/wikitech/277357?do=post_view_threaded#277357
> I was even told that wikimedia doesn't need good security at all,
> because user accounts aren't so critical there), forcing SSL will not
> improve it much
>

I think you need to check those facts.  How many years do you have to go
back before the extra CPU needed for a client to decrypt an SSL connection
becomes noticeable on a client?  Or how many browser versions before
support becomes imperfect?  SSL support was introduced in Internet Explorer
version *Two*, in 1995.

SSL is about much more than just preventing account hijacking.  It hides
details of what you're doing and what pages you're reading from people who
have no right or need to know.  In some jurisdictions, the correlation
between the publicly-available content of a comment or edit, and the
snoopable identity of the person who made it, can be damning.  The more
routine and commonplace SSL connections are, the safer the people who are
protected by it will be.

--HM
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Luis Villa
In reply to this post by Petr Bena
On Tue, Apr 30, 2013 at 10:27 AM, Petr Bena <[hidden email]> wrote:
> SSL is requiring more CPU,

Not really.

"In January this year (2010), Gmail switched to using HTTPS for
everything by default. Previously it had been introduced as an option,
but now all of our users use HTTPS to secure their email between their
browsers and Google, all the time. In order to do this we had to
deploy no additional machines and no special hardware. On our
production frontend machines, SSL/TLS accounts for less than 1% of the
CPU load, less than 10KB of memory per connection and less than 2% of
network overhead. Many people believe that SSL takes a lot of CPU time
and we hope the above numbers (public for the first time) will help to
dispel that."

http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

Luis



> both on server and client and disable all
> kinds of cache (such as squid or varnish), and some browsers may have
> problems with it OR in some countries encryption may be even illegal.
>
> Whatever you are going to do, you should let people turn it off.
> Wikimedia project itself has horrible security (in this thread I
> started some time ago -
> http://www.gossamer-threads.com/lists/wiki/wikitech/277357?do=post_view_threaded#277357
> I was even told that wikimedia doesn't need good security at all,
> because user accounts aren't so critical there), forcing SSL will not
> improve it much
>
> On Tue, Apr 30, 2013 at 6:30 AM, Paul Selitskas <[hidden email]> wrote:
>> On Tue, Apr 30, 2013 at 5:55 AM, Tyler Romeo <[hidden email]> wrote:
>>> On Mon, Apr 29, 2013 at 9:07 PM, Paul Selitskas <[hidden email]>wrote:
>>>
>>>> There are some situations when HTTPS won't work (for example, blocked
>>>> by provider or government). How does one disable HTTPS without
>>>> actually accessing a HTTPS version if the user is redirected from HTTP
>>>> automatically?
>>>>
>>>> HTTPS was once blocked in Belarus, thus disabling access to above
>>>> mentioned GMail, Facebook, Twitter and so on. There should be always
>>>> an option (like ?noSecure=1).
>>>>
>>>
>>> Well, with $wgSecureLogin the idea is that it is completely disallowed to
>>> log in, i.e., enter a password, over an insecure connection.
>>>
>>
>> Ah, I missed that moment. Thanks.
>>
>> --
>> З павагай,
>> Павел Селіцкас/Pavel Selitskas
>> Wizardist @ Wikimedia projects
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Luis Villa
Deputy General Counsel
Wikimedia Foundation
415.839.6885 ext. 6810

NOTICE: This message may be confidential or legally privileged. If you
have received it by accident, please delete it and let us know about
the mistake. As an attorney for the Wikimedia Foundation, for
legal/ethical reasons I cannot give legal advice to, or serve as a
lawyer for, community members, volunteers, or staff members in their
personal capacity.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Petr Bena
Ok, I agree with both of you that ssl is probably no deal for current
machines and browsers. But anyway - I am afraid that /forcing/ people
to use anything is a bad idea. It should be up to them to do what they
like on their own risk.

There are countries where encryption is illegal (not really expert on
that, but I heard that in Iran and such countries encryption is
problem), and these people would not be able to register / edit
wikipedia using an account if you made it a requirement.

First step should be just making it a default option for everyone,
before actually enforcing anybody.

On Tue, Apr 30, 2013 at 7:52 PM, Luis Villa <[hidden email]> wrote:

> On Tue, Apr 30, 2013 at 10:27 AM, Petr Bena <[hidden email]> wrote:
>> SSL is requiring more CPU,
>
> Not really.
>
> "In January this year (2010), Gmail switched to using HTTPS for
> everything by default. Previously it had been introduced as an option,
> but now all of our users use HTTPS to secure their email between their
> browsers and Google, all the time. In order to do this we had to
> deploy no additional machines and no special hardware. On our
> production frontend machines, SSL/TLS accounts for less than 1% of the
> CPU load, less than 10KB of memory per connection and less than 2% of
> network overhead. Many people believe that SSL takes a lot of CPU time
> and we hope the above numbers (public for the first time) will help to
> dispel that."
>
> http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>
> Luis
>
>
>
>> both on server and client and disable all
>> kinds of cache (such as squid or varnish), and some browsers may have
>> problems with it OR in some countries encryption may be even illegal.
>>
>> Whatever you are going to do, you should let people turn it off.
>> Wikimedia project itself has horrible security (in this thread I
>> started some time ago -
>> http://www.gossamer-threads.com/lists/wiki/wikitech/277357?do=post_view_threaded#277357
>> I was even told that wikimedia doesn't need good security at all,
>> because user accounts aren't so critical there), forcing SSL will not
>> improve it much
>>
>> On Tue, Apr 30, 2013 at 6:30 AM, Paul Selitskas <[hidden email]> wrote:
>>> On Tue, Apr 30, 2013 at 5:55 AM, Tyler Romeo <[hidden email]> wrote:
>>>> On Mon, Apr 29, 2013 at 9:07 PM, Paul Selitskas <[hidden email]>wrote:
>>>>
>>>>> There are some situations when HTTPS won't work (for example, blocked
>>>>> by provider or government). How does one disable HTTPS without
>>>>> actually accessing a HTTPS version if the user is redirected from HTTP
>>>>> automatically?
>>>>>
>>>>> HTTPS was once blocked in Belarus, thus disabling access to above
>>>>> mentioned GMail, Facebook, Twitter and so on. There should be always
>>>>> an option (like ?noSecure=1).
>>>>>
>>>>
>>>> Well, with $wgSecureLogin the idea is that it is completely disallowed to
>>>> log in, i.e., enter a password, over an insecure connection.
>>>>
>>>
>>> Ah, I missed that moment. Thanks.
>>>
>>> --
>>> З павагай,
>>> Павел Селіцкас/Pavel Selitskas
>>> Wizardist @ Wikimedia projects
>>>
>>> _______________________________________________
>>> Wikitech-l mailing list
>>> [hidden email]
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> Luis Villa
> Deputy General Counsel
> Wikimedia Foundation
> 415.839.6885 ext. 6810
>
> NOTICE: This message may be confidential or legally privileged. If you
> have received it by accident, please delete it and let us know about
> the mistake. As an attorney for the Wikimedia Foundation, for
> legal/ethical reasons I cannot give legal advice to, or serve as a
> lawyer for, community members, volunteers, or staff members in their
> personal capacity.
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Petr Bena
BTW there are not only common browsers like internet explorer which
are getting content from wikipedia, but even less common browsers,
such as bots, which are sometimes written in languages, where even if
it's not impossible, it at least adds 1 more level of complexity for
programmer to make them work.

Some of you who know me, probably know that I am really lazy guy. And
I was cursing Ryan Lane for enforcing ssl on wikitech when I had to
implement some certificate handling and ssl handshake into wm-bot
which is retrieving some data from it using api (reorad only - wm-bot
doesn't even have mediawiki user account). It took me like 20 minutes
to implement it and that was really horrid :D Think of all these poor
programmers, who wrote their wikimedia bot in assembler or
brainfuck... try to implement ssl in that first :P

On Tue, Apr 30, 2013 at 8:02 PM, Petr Bena <[hidden email]> wrote:

> Ok, I agree with both of you that ssl is probably no deal for current
> machines and browsers. But anyway - I am afraid that /forcing/ people
> to use anything is a bad idea. It should be up to them to do what they
> like on their own risk.
>
> There are countries where encryption is illegal (not really expert on
> that, but I heard that in Iran and such countries encryption is
> problem), and these people would not be able to register / edit
> wikipedia using an account if you made it a requirement.
>
> First step should be just making it a default option for everyone,
> before actually enforcing anybody.
>
> On Tue, Apr 30, 2013 at 7:52 PM, Luis Villa <[hidden email]> wrote:
>> On Tue, Apr 30, 2013 at 10:27 AM, Petr Bena <[hidden email]> wrote:
>>> SSL is requiring more CPU,
>>
>> Not really.
>>
>> "In January this year (2010), Gmail switched to using HTTPS for
>> everything by default. Previously it had been introduced as an option,
>> but now all of our users use HTTPS to secure their email between their
>> browsers and Google, all the time. In order to do this we had to
>> deploy no additional machines and no special hardware. On our
>> production frontend machines, SSL/TLS accounts for less than 1% of the
>> CPU load, less than 10KB of memory per connection and less than 2% of
>> network overhead. Many people believe that SSL takes a lot of CPU time
>> and we hope the above numbers (public for the first time) will help to
>> dispel that."
>>
>> http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>>
>> Luis
>>
>>
>>
>>> both on server and client and disable all
>>> kinds of cache (such as squid or varnish), and some browsers may have
>>> problems with it OR in some countries encryption may be even illegal.
>>>
>>> Whatever you are going to do, you should let people turn it off.
>>> Wikimedia project itself has horrible security (in this thread I
>>> started some time ago -
>>> http://www.gossamer-threads.com/lists/wiki/wikitech/277357?do=post_view_threaded#277357
>>> I was even told that wikimedia doesn't need good security at all,
>>> because user accounts aren't so critical there), forcing SSL will not
>>> improve it much
>>>
>>> On Tue, Apr 30, 2013 at 6:30 AM, Paul Selitskas <[hidden email]> wrote:
>>>> On Tue, Apr 30, 2013 at 5:55 AM, Tyler Romeo <[hidden email]> wrote:
>>>>> On Mon, Apr 29, 2013 at 9:07 PM, Paul Selitskas <[hidden email]>wrote:
>>>>>
>>>>>> There are some situations when HTTPS won't work (for example, blocked
>>>>>> by provider or government). How does one disable HTTPS without
>>>>>> actually accessing a HTTPS version if the user is redirected from HTTP
>>>>>> automatically?
>>>>>>
>>>>>> HTTPS was once blocked in Belarus, thus disabling access to above
>>>>>> mentioned GMail, Facebook, Twitter and so on. There should be always
>>>>>> an option (like ?noSecure=1).
>>>>>>
>>>>>
>>>>> Well, with $wgSecureLogin the idea is that it is completely disallowed to
>>>>> log in, i.e., enter a password, over an insecure connection.
>>>>>
>>>>
>>>> Ah, I missed that moment. Thanks.
>>>>
>>>> --
>>>> З павагай,
>>>> Павел Селіцкас/Pavel Selitskas
>>>> Wizardist @ Wikimedia projects
>>>>
>>>> _______________________________________________
>>>> Wikitech-l mailing list
>>>> [hidden email]
>>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>>> _______________________________________________
>>> Wikitech-l mailing list
>>> [hidden email]
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>>
>>
>> --
>> Luis Villa
>> Deputy General Counsel
>> Wikimedia Foundation
>> 415.839.6885 ext. 6810
>>
>> NOTICE: This message may be confidential or legally privileged. If you
>> have received it by accident, please delete it and let us know about
>> the mistake. As an attorney for the Wikimedia Foundation, for
>> legal/ethical reasons I cannot give legal advice to, or serve as a
>> lawyer for, community members, volunteers, or staff members in their
>> personal capacity.
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Daniel Friesen-2
In reply to this post by Petr Bena
On Tue, 30 Apr 2013 10:27:21 -0700, Petr Bena <[hidden email]> wrote:

> SSL is requiring more CPU, both on server and client and disable all
> kinds of cache (such as squid or varnish), and some browsers may have
> problems with it OR in some countries encryption may be even illegal.

SSL does not disable caches. SSL is terminated at the cluster,  
Squid/Varnish are in on the raw HTTP and serve out HTTP EXACTLY the same  
way they serve out normal HTTP requests (they even use the exact same  
cache thanks to our protocol relative urls).

And aside from a few special edge cases, browser caches also work  
perfectly fine over https as well.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Faidon Liambotis
On Tue, Apr 30, 2013 at 11:14:48AM -0700, Daniel Friesen wrote:

> On Tue, 30 Apr 2013 10:27:21 -0700, Petr Bena <[hidden email]> wrote:
>
> >SSL is requiring more CPU, both on server and client and disable all
> >kinds of cache (such as squid or varnish), and some browsers may have
> >problems with it OR in some countries encryption may be even illegal.
>
> SSL does not disable caches. SSL is terminated at the cluster,
> Squid/Varnish are in on the raw HTTP and serve out HTTP EXACTLY the
> same way they serve out normal HTTP requests (they even use the
> exact same cache thanks to our protocol relative urls).
 
I can verify that the above is correct and Petr is wrong.

However, we terminate SSL before proxying to the normal caching layers,
and the infrastructure for this is too small to handle significant
portions of the traffic (if it were bigger, it'd be a waste of resources
and hence money, considering its current usage). If we were to push
normal traffic to them, we'd quickly reach all kinds of limits, incl.
CPU and network.

That isn't to say that it's impossible to scale up this infrastructure
if needed (or, more likely, adapt the design of the infrastructure to
incorporate such an expansion by putting it closer to the caching
layers), but it should be considered that it's not just about enabling a
MediaWiki config setting to do this but also involves other
operations-related engineering work.

That being said, my gut tells me that making all the logins SSL-enabled
is not going to make a significant difference compared to current usage,
but I don't have any numbers to back this up right now. Maybe Ryan has
them.

Cheers,
Faidon

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Chris Steipp
On Tue, Apr 30, 2013 at 12:00 PM, Faidon Liambotis <[hidden email]> wrote:
> That being said, my gut tells me that making all the logins SSL-enabled
> is not going to make a significant difference compared to current usage,
> but I don't have any numbers to back this up right now. Maybe Ryan has
> them.

We enabled it for about an hour previously (before reverting due to
the centralauth bug), and the change was barely noticeable in ganglia.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Tyler Romeo
In reply to this post by Petr Bena
On Tue, Apr 30, 2013 at 2:02 PM, Petr Bena <[hidden email]> wrote:

> But anyway - I am afraid that /forcing/ people
> to use anything is a bad idea.
>

^this. Yes, using HTTPS everywhere is more secure and is probably what WMF
will move toward. But no reason has yet to be provided why we should force
all wikis everywhere to be all or none, especially when the difference
between forcing everybody and giving the option is trivial (to adjust my
patch to make it a forcing patch is literally a few lines of code).

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | [hidden email]
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Countdown to SSL for all sessions?

Matthew Walker
In reply to this post by Chris Steipp
>
> We enabled it for about an hour previously (before reverting due to
> the centralauth bug), and the change was barely noticeable in ganglia.


Do we have numbers on what this did to the number of active editors during
that time period? Esp. broken down on a per country basis?

I think I want to agree with Petr -- we should not be forcing SSL always;
we should be respecting what the user requested. In that way if it ever
becomes enforced by a government that SSL is disallowed users may still
contribute to the site. (Remember we block things like Tor so they can't
even proxy around it.)

Perhaps we should just make it really obvious on the login page (e.g. big
button to login via SSL, small button to not do so.)

~Matt Walker
Wikimedia Foundation
Fundraising Technology Team


On Tue, Apr 30, 2013 at 12:21 PM, Chris Steipp <[hidden email]>wrote:

> On Tue, Apr 30, 2013 at 12:00 PM, Faidon Liambotis <[hidden email]>
> wrote:
> > That being said, my gut tells me that making all the logins SSL-enabled
> > is not going to make a significant difference compared to current usage,
> > but I don't have any numbers to back this up right now. Maybe Ryan has
> > them.
>
> We enabled it for about an hour previously (before reverting due to
> the centralauth bug), and the change was barely noticeable in ganglia.
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12