Conrad Irwin conrad.irwin at gmail.com writes:
There is no real massive load caused by https at runtime. There is however
a significant chink of developer and sysadmin time needed to implement this
and make it work.
Secure login in itself shouldn't require reconfiguration of the SSL
On 26/10/10 08:45, George Herbert wrote:
The current WMF situation is becoming quaint - pros use
secure.wikimedia.org, amateurs don't realize what they're exposing.
I released a small patch today that let a user login with HTTPS. It is
in trunk as r75585 :
On Mon, Oct 25, 2010 at 11:23 PM, Ashar Voultoiz hashar+...@free.fr wrote:
On 25/10/10 23:26, George Herbert wrote:
I for one only use secure.wikimedia.org; I would like to urge as a
general course that the Foundation switch to a HTTPS by default
strategy...
HTTPS means full encryption, that
George Herbert wrote:
The current WMF situation is becoming quaint - pros use
secure.wikimedia.org, amateurs don't realize what they're exposing.
By professional standards, we're not keeping up with professional
industry expectations. It's not nuclear bomb secrets (cough) or
missile designs
On Mon, Oct 25, 2010 at 11:59 PM, MZMcBride z...@mzmcbride.com wrote:
George Herbert wrote:
The current WMF situation is becoming quaint - pros use
secure.wikimedia.org, amateurs don't realize what they're exposing.
By professional standards, we're not keeping up with professional
industry
On 10/26/2010 08:59 AM, MZMcBride wrote:
As Aryeh notes, even those who act in an editing role (rather than in simply
a reader role) don't generally have valuable accounts. The pros you're
talking about are free to use secure.wikimedia.org (which is already set up
and has been for quite some
On Tue, Oct 26, 2010 at 6:24 PM, George Herbert
george.herb...@gmail.com wrote:
..
But I would prefer to move towards a logged-in user by default goes to
secure connection model. That would include making secure a
multi-system, fully redundantly supported part of the environment, or
On 26.10.2010 09:36, Nikola Smolenski wrote:
On 10/26/2010 08:59 AM, MZMcBride wrote:
As Aryeh notes, even those who act in an editing role (rather than in simply
a reader role) don't generally have valuable accounts. The pros you're
talking about are free to use secure.wikimedia.org (which is
There is no real massive load caused by https at runtime. There is however
a significant chink of developer and sysadmin time needed to implement this
and make it work.
For now, at least, the only optimisations that should be considered are
those that make it easier all round.
Conrad
On 26 Oct
On Tue, Oct 26, 2010 at 2:23 AM, Ashar Voultoiz hashar+...@free.fr wrote:
HTTPS means full encryption, that is either :
- a ton of CPU cycles : those are wasted cycles for something else.
- SSL ASIC : costly, specially given our gets/ bandwidth levels
HTTPS uses very few CPU cycles by
Has anyone seen this?
http://codebutler.com/firesheep
A new Firefox plugin that makes it trivially easy to hijack cookies
from a website that's using HTTP for login over an unencrypted
wireless network. Wikipedia isn't in the standard installation as a
site (lots of other sites, such as
On Mon, Oct 25, 2010 at 7:15 PM, Hay (Husky) hus...@gmail.com wrote:
Has anyone seen this?
http://codebutler.com/firesheep
A new Firefox plugin that makes it trivially easy to hijack cookies
from a website that's using HTTP for login over an unencrypted
wireless network. Wikipedia isn't in
2010/10/25 Marco Schuster ma...@harddisk.is-a-geek.org:
The admin in question doesn't even have to visit Wikipedia directly,
there are enough pages hotlinking to upload.wikimedia.org, which
should cause the browser to transmit session data.
Actually it won't, because upload.wikimedia.org is a
To really fix the problem we would have to go HTTPS by default. I don't
know what that means to our resource usage, as well as how it affects
people who cannot use HTTPS for whatever reason.
By the way, there is a plugin for Firefox called HTTPS Everywhere, which
will attempt to switch to
On Mon, Oct 25, 2010 at 2:45 PM, Neil Kandalgaonkar ne...@wikimedia.org wrote:
[snip]
but we do with commons.wikimedia.org, and there's no HTTPS
equivalent.
It's on secure.wikimedia.org, like all the other sites
https://secure.wikimedia.org/wikipedia/commons/wiki/Main_Page
-Chad
On Mon, Oct 25, 2010 at 1:15 PM, Hay (Husky) hus...@gmail.com wrote:
A new Firefox plugin that makes it trivially easy to hijack cookies
from a website that's using HTTP for login over an unencrypted
wireless network.
It doesn't hijack login, it hijacks cookies, so we're only protected
if we
On 25 October 2010 21:37, Aryeh Gregor simetrical+wikil...@gmail.com wrote:
http://en.wikipedia.org/wiki/Server_Name_Indication
But those might not be reliably usable yet.
Per the article, approximately no-one uses SNI as yet because IE on XP
will never be capable of it. (Firefox and Chrome
On Mon, Oct 25, 2010 at 1:37 PM, Aryeh Gregor
simetrical+wikil...@gmail.com wrote:
[...]
Anyway, this is all doable in principle, yes. It will probably impose
no significant processing overhead, CPUs are powerful enough today
that TLS shouldn't be a big deal. (I recall hearing that Google
On Tue, Oct 26, 2010 at 10:01 AM, Aryeh Gregor
simetrical+wikil...@gmail.com wrote:
Gmail typically contains things like credit card numbers, passwords,
maybe state secrets if you pick the right person
..
at most you could compromise an admin account
.. or an account with checkuser or
19 matches
Mail list logo
