Hello,
I'm sure this question has already been asked, but I can't find the answer.
I checked and my password is transmitted in clear text when I connect to my Wikipedia account. As an admin on a project, I feel very guilty to connect to my account on an unsecured public wifi : I'm afraid my password is caught one day or another.
I checked secure wikipedia but I could not find my project (fr.wikipedia.org ).
Is there a solution, except avoiding such unsecure networks?
Thanks! Plyd
Plyd wrote:
Hello,
I'm sure this question has already been asked, but I can't find the answer.
I checked and my password is transmitted in clear text when I connect to my Wikipedia account. As an admin on a project, I feel very guilty to connect to my account on an unsecured public wifi : I'm afraid my password is caught one day or another.
I checked secure wikipedia but I could not find my project (fr.wikipedia.org ).
Is there a solution, except avoiding such unsecure networks?
Thanks! Plyd
Use https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page
--vvv
On Mon, Aug 3, 2009 at 10:26 PM, Victor Vasilievvasilvv@gmail.com wrote:
Plyd wrote:
Hello,
I'm sure this question has already been asked, but I can't find the answer.
I checked and my password is transmitted in clear text when I connect to my Wikipedia account. As an admin on a project, I feel very guilty to connect to my account on an unsecured public wifi : I'm afraid my password is caught one day or another.
I checked secure wikipedia but I could not find my project (fr.wikipedia.org ).
Is there a solution, except avoiding such unsecure networks?
Thanks! Plyd
Use https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page
--vvv
Its https://secure.wikimedia.org/wikipedia/<LANGUAGE CODE>/wiki/Main_Page so for you wanting the french one it will be https://secure.wikimedia.org/wikipedia/fr/wiki/Main_Page
-Peachey
K. Peachey wrote:
Its https://secure.wikimedia.org/wikipedia/<LANGUAGE CODE>/wiki/Main_Page so for you wanting the french one it will be https://secure.wikimedia.org/wikipedia/fr/wiki/Main_Page
As it says on the insecure login:
http://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Connexion&returnt...
"Pour plus de sécurité, il est possible de se connecter via notre serveur sécurisé (aide)."
With the embedded link:
https://secure.wikimedia.org/wikipedia/fr/wiki/Special:Userlogin
William Allen Simpson wrote:
K. Peachey wrote:
Its https://secure.wikimedia.org/wikipedia/<LANGUAGE CODE>/wiki/Main_Page so for you wanting the french one it will be https://secure.wikimedia.org/wikipedia/fr/wiki/Main_Page
As it says on the insecure login:
http://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Connexion&returnt...
"Pour plus de sécurité, il est possible de se connecter via notre serveur sécurisé (aide)."
With the embedded link:
https://secure.wikimedia.org/wikipedia/fr/wiki/Special:Userlogin
I've noticed that images such as the sitelogo in the login page linked above are still served via HTTP, even when going through the secure server. This causes Firefox to regard the whole page as potentially compromised by unencrypted content, and it issues a warning message to that effect.
Although the user can click through that warning, it would be much better to have images served via HTTPS on pages from the secure server, rather than habituating users into clicking through warning messages.
-- Neil
On Mon, Aug 3, 2009 at 1:56 PM, Neil Harrisusenet@tonal.clara.co.uk wrote:
William Allen Simpson wrote:
K. Peachey wrote:
Its https://secure.wikimedia.org/wikipedia/<LANGUAGE CODE>/wiki/Main_Page so for you wanting the french one it will be https://secure.wikimedia.org/wikipedia/fr/wiki/Main_Page
As it says on the insecure login:
http://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Connexion&returnt...
"Pour plus de sécurité, il est possible de se connecter via notre serveur sécurisé (aide)."
With the embedded link:
https://secure.wikimedia.org/wikipedia/fr/wiki/Special:Userlogin
I've noticed that images such as the sitelogo in the login page linked above are still served via HTTP, even when going through the secure server. This causes Firefox to regard the whole page as potentially compromised by unencrypted content, and it issues a warning message to that effect.
Although the user can click through that warning, it would be much better to have images served via HTTPS on pages from the secure server, rather than habituating users into clicking through warning messages.
-- Neil
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
See https://bugzilla.wikimedia.org/show_bug.cgi?id=5440
-Chad
On 8/3/09 10:56 AM, Neil Harris wrote:
I've noticed that images such as the sitelogo in the login page linked above are still served via HTTP, even when going through the secure server. This causes Firefox to regard the whole page as potentially compromised by unencrypted content, and it issues a warning message to that effect.
Although the user can click through that warning, it would be much better to have images served via HTTPS on pages from the secure server, rather than habituating users into clicking through warning messages.
Yep, that's on my todo list for the ops boys this month. :)
Some BZ entries for your reference: https://bugzilla.wikimedia.org/show_bug.cgi?id=16822 https://bugzilla.wikimedia.org/show_bug.cgi?id=18496
also for interwiki links: https://bugzilla.wikimedia.org/show_bug.cgi?id=5440
and a note on some of the JS gadgets: https://bugzilla.wikimedia.org/show_bug.cgi?id=17966
Once we have a cleaner interface for hitting the general pages (without the 'secure.wikimedia.org' crappy single host) I'd also like us to get the login pages running always through SSL: https://bugzilla.wikimedia.org/show_bug.cgi?id=225 -- brion
On Mon, Aug 3, 2009 at 2:16 PM, Brion Vibber brion@wikimedia.org wrote:
Once we have a cleaner interface for hitting the general pages (without the 'secure.wikimedia.org' crappy single host)
I'm curious...what will this cleaner interface look like? Will we be able to connect securely through https://en.wikipedia.org/?
-- Remember the dot http://en.wikipedia.org/wiki/User:Remember_the_dot
On 8/3/09 6:28 PM, Remember the dot wrote:
On Mon, Aug 3, 2009 at 2:16 PM, Brion Vibberbrion@wikimedia.org wrote:
Once we have a cleaner interface for hitting the general pages (without the 'secure.wikimedia.org' crappy single host)
I'm curious...what will this cleaner interface look like? Will we be able to connect securely through https://en.wikipedia.org/?
That's the idea... This means we need SSL proxies available on all of our front-end proxies instead of just on a dedicated location, and some hoop-jumping to get certificate hostnames to match, but it's not impossible.
We did a little experimentation in '07 along these lines but just got busy with other things. :(
-- brion
On Tue, Aug 4, 2009 at 7:47 PM, Brion Vibberbrion@wikimedia.org wrote:
On 8/3/09 6:28 PM, Remember the dot wrote:
On Mon, Aug 3, 2009 at 2:16 PM, Brion Vibberbrion@wikimedia.org wrote:
Once we have a cleaner interface for hitting the general pages (without the 'secure.wikimedia.org' crappy single host)
I'm curious...what will this cleaner interface look like? Will we be able to connect securely through https://en.wikipedia.org/?
That's the idea... This means we need SSL proxies available on all of our front-end proxies instead of just on a dedicated location, and some hoop-jumping to get certificate hostnames to match, but it's not impossible.
We did a little experimentation in '07 along these lines but just got busy with other things. :(
A useful data point is that GreenReaper@Wikifur has switched to using protocol relative URLs rather than absolutes (i.e. "//host.domain.com/foo/bar") and had good luck with it. This is an additional data-point beyond the testing I did with en.wp last year. (Last year while doing some ipv6 testing I also tested protocol relatives and determined that all the clients with JS support were unharmed by protocol relatives).
Ironically— the existence of secure.wikimedia.org with insecure images is the only obstruction I see to switching images on the production sites to protocol relatives in order to confirm client compatibility.
(For those following at home: If Wikimedia can use protocol relatives as a global replacement for absolutes to its own domains we can avoid inadvertent secure/insecure mode switching and leaks without having to have two copies of the article cache data and without kludgy on-the-fly rewriting)
wikitech-l@lists.wikimedia.org