Jimmy just tweeted this:
https://twitter.com/jimmy_wales/status/362626509648834560
I think that's the first time I've seen him say "fuck" in a public communication ...
Anyway, I expect people will ask us how the move to all-SSL is progressing. So, how is it going?
(I've been telling people it's slowly moving along, we totally want this, it's just technical resources. But more details would be most useful!)
- d.
Good question.
There are two steps to this: 1) Move all logins to TLS 2) Move all logged in users to TLS
The former was dependent on a bug with E:CentralAuth that was causing $wgSecureLogin to malfunction. I am not sure whether this bug was ever fixed (I remember seeing Chris submit a patch for it, but I think it was abandoned).
Also, the discussion on https://bugzilla.wikimedia.org/show_bug.cgi?id=52283 is probably a blocker for enabled $wgSecureLogin (which would be a pre-requisite for either of the two above steps).
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Jul 31, 2013 at 2:36 PM, David Gerard dgerard@gmail.com wrote:
Jimmy just tweeted this:
https://twitter.com/jimmy_wales/status/362626509648834560
I think that's the first time I've seen him say "fuck" in a public communication ...
Anyway, I expect people will ask us how the move to all-SSL is progressing. So, how is it going?
(I've been telling people it's slowly moving along, we totally want this, it's just technical resources. But more details would be most useful!)
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Jul 31, 2013 at 11:40 AM, Tyler Romeo tylerromeo@gmail.com wrote:
Good question.
There are two steps to this:
- Move all logins to TLS
- Move all logged in users to TLS
3) Serve all traffic via HTTPS 4) With PFS and long HSTS timeouts
The former was dependent on a bug with E:CentralAuth that was causing $wgSecureLogin to malfunction. I am not sure whether this bug was ever fixed (I remember seeing Chris submit a patch for it, but I think it was abandoned).
The bug has been fixes as part of the new SUL code. Yay!
Also, the discussion on https://bugzilla.wikimedia.org/show_bug.cgi?id=52283 is probably a blocker for enabled $wgSecureLogin (which would be a pre-requisite for either of the two above steps).
As a few people noticed, we actually threw the switch on wgSecureLogin yesterday, at which point the UX people felt that experience wasn't ready, and it was reverted. This bug was one of the issues identified, where they felt the UX would actually harm the editor experience.
We also have some scaling concerns, so ops is also working on making sure we have enough capacity on hand to handle major spikes after we enable this. Hopefully we'll tie up all the loose ends in the near future, and can try getting to step #1 again.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Jul 31, 2013 at 2:36 PM, David Gerard dgerard@gmail.com wrote:
Jimmy just tweeted this:
https://twitter.com/jimmy_wales/status/362626509648834560
I think that's the first time I've seen him say "fuck" in a public communication ...
Anyway, I expect people will ask us how the move to all-SSL is progressing. So, how is it going?
(I've been telling people it's slowly moving along, we totally want this, it's just technical resources. But more details would be most useful!)
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Jul 31, 2013 at 2:50 PM, Chris Steipp csteipp@wikimedia.org wrote:
- Serve all traffic via HTTPS
- With PFS and long HSTS timeouts
Indeed. I need to be more optimistic. :)
The bug has been fixes as part of the new SUL code. Yay!
Nice!
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
Which kind of ignores the issue that encrypting with ssl doesn't do a lot against traffic analysis, when its publicly known how big the pages you're downloading are, and how many images/other assets they have on them. NSA certainly has the resources to do this if they want.
If you can do this sort of thing: http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html against google maps, I imagine it should be much simpler to do something like that for Wikipedia. (Our data has more variation in it, and the data is all publicly available)
--bawolff
On 7/31/13, Tyler Romeo tylerromeo@gmail.com wrote:
Good question.
There are two steps to this:
- Move all logins to TLS
- Move all logged in users to TLS
The former was dependent on a bug with E:CentralAuth that was causing $wgSecureLogin to malfunction. I am not sure whether this bug was ever fixed (I remember seeing Chris submit a patch for it, but I think it was abandoned).
Also, the discussion on https://bugzilla.wikimedia.org/show_bug.cgi?id=52283 is probably a blocker for enabled $wgSecureLogin (which would be a pre-requisite for either of the two above steps).
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Jul 31, 2013 at 2:36 PM, David Gerard dgerard@gmail.com wrote:
Jimmy just tweeted this:
https://twitter.com/jimmy_wales/status/362626509648834560
I think that's the first time I've seen him say "fuck" in a public communication ...
Anyway, I expect people will ask us how the move to all-SSL is progressing. So, how is it going?
(I've been telling people it's slowly moving along, we totally want this, it's just technical resources. But more details would be most useful!)
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Jul 31, 2013 at 11:55 AM, Brian Wolff bawolff@gmail.com wrote:
Which kind of ignores the issue that encrypting with ssl doesn't do a lot against traffic analysis, when its publicly known how big the pages you're downloading are, and how many images/other assets they have on them. NSA certainly has the resources to do this if they want.
If you can do this sort of thing: http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html against google maps, I imagine it should be much simpler to do something like that for Wikipedia. (Our data has more variation in it, and the data is all publicly available)
--bawolff
Time to start adding a random amount of extra packets with each request? :)
James Alexander Legal and Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
On Jul 31, 2013, at 3:01 PM, James Alexander jalexander@wikimedia.org wrote:
Time to start adding a random amount of extra packets with each request? :)
This is what freenet does, but I think supporting SPDY/HTTP 2.0 [1] will help in this regard as well, as it essentially pipelines requests (so you wouldn't be able to discern which packets were article body, for example).
--Ken.
Like dgerald said, let's not let the perfect distract us from the better. It will be impossible to 100% secure our visitors' traffic against an adversary with as many resources as the NSA. But we can secure our users against adversaries with fewer resources, and we can increase the cost of a successful attack so that casual snooping on everyone and every article isn't possible. Let's make the NSA use that expensive targetted 'trafficthief' program at the top of their pyramid, instead of letting them cheaply/casually sniff everything with xkeyscore. --scott
Time to start adding a random amount of extra packets with each request? :)
We would need to be very careful to not cause detectable entropy changes which is not trivial!
Perhaps we promote the deployment of SPDY/QUIC which interleaves requests?
~Matt Walker Wikimedia Foundation Fundraising Technology Team
On Wed, Jul 31, 2013 at 12:01 PM, James Alexander jalexander@wikimedia.orgwrote:
On Wed, Jul 31, 2013 at 11:55 AM, Brian Wolff bawolff@gmail.com wrote:
Which kind of ignores the issue that encrypting with ssl doesn't do a lot against traffic analysis, when its publicly known how big the pages you're downloading are, and how many images/other assets they have on them. NSA certainly has the resources to do this if they want.
If you can do this sort of thing:
http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html
against google maps, I imagine it should be much simpler to do something like that for Wikipedia. (Our data has more variation in it, and the data is all publicly available)
--bawolff
Time to start adding a random amount of extra packets with each request? :)
James Alexander Legal and Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
There was the lofty notion of including all images, CSS/JS/whatnot as CDATA elements in the page itself, for browsers that support it. That would get around the one issue, but still allow size-based fingerprinting, especially since most users will follow links within the site, so the search space gets much smaller. Random package size increase, as mentioned, might help there.
Magnus
On Wed, Jul 31, 2013 at 7:55 PM, Brian Wolff bawolff@gmail.com wrote:
Which kind of ignores the issue that encrypting with ssl doesn't do a lot against traffic analysis, when its publicly known how big the pages you're downloading are, and how many images/other assets they have on them. NSA certainly has the resources to do this if they want.
If you can do this sort of thing: http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html against google maps, I imagine it should be much simpler to do something like that for Wikipedia. (Our data has more variation in it, and the data is all publicly available)
--bawolff
On 7/31/13, Tyler Romeo tylerromeo@gmail.com wrote:
Good question.
There are two steps to this:
- Move all logins to TLS
- Move all logged in users to TLS
The former was dependent on a bug with E:CentralAuth that was causing $wgSecureLogin to malfunction. I am not sure whether this bug was ever fixed (I remember seeing Chris submit a patch for it, but I think it was abandoned).
Also, the discussion on
https://bugzilla.wikimedia.org/show_bug.cgi?id=52283
is probably a blocker for enabled $wgSecureLogin (which would be a pre-requisite for either of the two above steps).
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Jul 31, 2013 at 2:36 PM, David Gerard dgerard@gmail.com wrote:
Jimmy just tweeted this:
https://twitter.com/jimmy_wales/status/362626509648834560
I think that's the first time I've seen him say "fuck" in a public communication ...
Anyway, I expect people will ask us how the move to all-SSL is progressing. So, how is it going?
(I've been telling people it's slowly moving along, we totally want this, it's just technical resources. But more details would be most useful!)
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Just one question from a relatively non-technical person: What falls off the map if everything is done using SSL? Is this the protocol that would make it essentially impossible to read/edit Wikipedia using a normal internet connection from China?
Risker
On 31 July 2013 15:12, Magnus Manske magnusmanske@googlemail.com wrote:
There was the lofty notion of including all images, CSS/JS/whatnot as CDATA elements in the page itself, for browsers that support it. That would get around the one issue, but still allow size-based fingerprinting, especially since most users will follow links within the site, so the search space gets much smaller. Random package size increase, as mentioned, might help there.
Magnus
On Wed, Jul 31, 2013 at 7:55 PM, Brian Wolff bawolff@gmail.com wrote:
Which kind of ignores the issue that encrypting with ssl doesn't do a lot against traffic analysis, when its publicly known how big the pages you're downloading are, and how many images/other assets they have on them. NSA certainly has the resources to do this if they want.
If you can do this sort of thing:
http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html
against google maps, I imagine it should be much simpler to do something like that for Wikipedia. (Our data has more variation in it, and the data is all publicly available)
--bawolff
On 7/31/13, Tyler Romeo tylerromeo@gmail.com wrote:
Good question.
There are two steps to this:
- Move all logins to TLS
- Move all logged in users to TLS
The former was dependent on a bug with E:CentralAuth that was causing $wgSecureLogin to malfunction. I am not sure whether this bug was ever fixed (I remember seeing Chris submit a patch for it, but I think it
was
abandoned).
Also, the discussion on
https://bugzilla.wikimedia.org/show_bug.cgi?id=52283
is probably a blocker for enabled $wgSecureLogin (which would be a pre-requisite for either of the two above steps).
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Jul 31, 2013 at 2:36 PM, David Gerard dgerard@gmail.com
wrote:
Jimmy just tweeted this:
https://twitter.com/jimmy_wales/status/362626509648834560
I think that's the first time I've seen him say "fuck" in a public communication ...
Anyway, I expect people will ask us how the move to all-SSL is progressing. So, how is it going?
(I've been telling people it's slowly moving along, we totally want this, it's just technical resources. But more details would be most useful!)
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- undefined _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 07/31/2013 03:23 PM, Risker wrote:
Just one question from a relatively non-technical person: What falls off the map if everything is done using SSL? Is this the protocol that would make it essentially impossible to read/edit Wikipedia using a normal internet connection from China?
Risker
Good question. I'm not aware of the current status, but Tim Starling said SSL connections to Wikipedia have been blocked in China (https://bugzilla.wikimedia.org/show_bug.cgi?id=47832#c16).
Matt Flaschen
Like I've said before, the NSA spying on what users are reading is still the least of our concerns. We should focus on making sure passwords aren't sent over plaintext before attempting to evade a government-run international spy network.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Jul 31, 2013 at 4:32 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 07/31/2013 03:23 PM, Risker wrote:
Just one question from a relatively non-technical person: What falls off the map if everything is done using SSL? Is this the protocol that would make it essentially impossible to read/edit Wikipedia using a normal internet connection from China?
Risker
Good question. I'm not aware of the current status, but Tim Starling said SSL connections to Wikipedia have been blocked in China (https://bugzilla.wikimedia.org/show_bug.cgi?id=47832#c16).
Matt Flaschen
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Can we enable full security mode (as an optional feature) geographically based on the most concerned governments, if the whole thing isn't going fast due to lack of resources?
On Wed, Jul 31, 2013 at 11:35 PM, Tyler Romeo tylerromeo@gmail.com wrote:
Like I've said before, the NSA spying on what users are reading is still the least of our concerns. We should focus on making sure passwords aren't sent over plaintext before attempting to evade a government-run international spy network.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Jul 31, 2013 at 4:32 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 07/31/2013 03:23 PM, Risker wrote:
Just one question from a relatively non-technical person: What falls
off
the map if everything is done using SSL? Is this the protocol that
would
make it essentially impossible to read/edit Wikipedia using a normal internet connection from China?
Risker
Good question. I'm not aware of the current status, but Tim Starling said SSL connections to Wikipedia have been blocked in China (https://bugzilla.wikimedia.org/show_bug.cgi?id=47832#c16).
Matt Flaschen
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Jul 31, 2013 at 1:39 PM, Paul Selitskas p.selitskas@gmail.comwrote:
Can we enable full security mode (as an optional feature) geographically based on the most concerned governments, if the whole thing isn't going fast due to lack of resources?
No. That's in fact much, much harder.
There's nothing stopping you (and anyone else who is concerned about their privacy) from using HTTPS Everywhere. We support HTTPS natively as is right now.
- Ryan
Yes, that is exactly what I do. But Google, for instance, redirects me to HTTP, and if I've logged via HTTPS recently, I would have to log in once again via HTTP. It's very frustrating. Are there public statistics on HTTPS v. HTTP processed requests share for Wikimedia? Rough numbers?
For inexperienced users yet concerned about privacy, there should be an HTTP/HTTPS switch in the Preferences page. We have one at the registration/log-in page, but I'd like MediaWiki to remember that I want to use HTTPS only.
On Wed, Jul 31, 2013 at 11:50 PM, Ryan Lane rlane32@gmail.com wrote:
On Wed, Jul 31, 2013 at 1:39 PM, Paul Selitskas <p.selitskas@gmail.com
wrote:
Can we enable full security mode (as an optional feature) geographically based on the most concerned governments, if the whole thing isn't going fast due to lack of resources?
No. That's in fact much, much harder.
There's nothing stopping you (and anyone else who is concerned about their privacy) from using HTTPS Everywhere. We support HTTPS natively as is right now.
- Ryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
@Paul - Some links that might interest you.
On Wed, Jul 31, 2013 at 4:56 PM, Paul Selitskas p.selitskas@gmail.comwrote:
But Google, for instance, redirects me to HTTP
https://bugzilla.wikimedia.org/show_bug.cgi?id=51002
For inexperienced users yet concerned about privacy, there should be an
HTTP/HTTPS switch in the Preferences page. We have one at the registration/log-in page, but I'd like MediaWiki to remember that I want to use HTTPS only.
https://bugzilla.wikimedia.org/show_bug.cgi?id=52283 https://gerrit.wikimedia.org/r/47089
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Jul 31, 2013 at 8:56 PM, Paul Selitskas p.selitskas@gmail.com wrote:
Yes, that is exactly what I do. But Google, for instance, redirects me to HTTP, and if I've logged via HTTPS recently, I would have to log in once again via HTTP. It's very frustrating.
I think you've misinterpreted. "HTTPS Everywhere" is a proper noun. https://www.eff.org/https-everywhere
Are there public statistics on HTTPS v. HTTP processed requests share for Wikimedia? Rough numbers?
I have no idea.
For inexperienced users yet concerned about privacy, there should be an HTTP/HTTPS switch in the Preferences page. We have one at the registration/log-in page, but I'd like MediaWiki to remember that I want to use HTTPS only.
That was considered but I believe the consensus was not to do that. Instead we will (eventually) force all logged in users to HTTPS as long as they're logged in. (So like your proposal except that the preference is hidden and always enabled for everyone)
-Jeremy
On 07/31/2013 04:35 PM, Tyler Romeo wrote:
Like I've said before, the NSA spying on what users are reading is still the least of our concerns. We should focus on making sure passwords aren't sent over plaintext before attempting to evade a government-run international spy network.
I'm not sure what that has to do with the the message you replied to. I completely support rolling out HTTPS where possible (I'm using HTTPS Everywhere already).
I was agreeing that we need to be aware of Risker's concern (other people have mentioned it too, of course) that we not effectively lock out users in China and other countries that may block SSL. It's important to remember that people in China still can and do edit Wikipedias in other languages, too.
This applies if we mandate secure login in such countries, too.
As for government-run spy networks, we don't know what their full capabilities are. But there are plenty of benefits to rolling out SSL regardless, even just for privacy from the person at the other end of the coffee shop. Firesheep, anyone?
Matt Flaschen
On Wed, Jul 31, 2013 at 5:29 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
I'm not sure what that has to do with the the message you replied to. I completely support rolling out HTTPS where possible (I'm using HTTPS Everywhere already).
Sorry I might have highlighted the wrong message when replying. I was referring to the discussion about how TLS doesn't entirely solve the problem and that we should start adding random packets in order to prevent traffic analysis.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
As for government-run spy networks, we don't know what their full capabilities are. But there are plenty of benefits to rolling out SSL regardless, even just for privacy from the person at the other end of the coffee shop. Firesheep, anyone?
Matt Flaschen
I agree that there's lots of benefits to ssl, and its something that we really should do. I just think we should be clear on our threat model, and not mislead people into thinking it will protect them from an entity with the resources of a state. SSL is too often banded about as being something which will totally prevent government type spying.
--bawolff
Also, on a side note, Facebook *just* made HTTPS the default:
https://www.facebook.com/notes/facebook-engineering/secure-browsing-by-defau...
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Jul 31, 2013 at 6:03 PM, Brian Wolff bawolff@gmail.com wrote:
As for government-run spy networks, we don't know what their full capabilities are. But there are plenty of benefits to rolling out SSL regardless, even just for privacy from the person at the other end of the coffee shop. Firesheep, anyone?
Matt Flaschen
I agree that there's lots of benefits to ssl, and its something that we really should do. I just think we should be clear on our threat model, and not mislead people into thinking it will protect them from an entity with the resources of a state. SSL is too often banded about as being something which will totally prevent government type spying.
--bawolff
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Jul 31, 2013 at 5:22 PM, Tyler Romeo tylerromeo@gmail.com wrote:
Also, on a side note, Facebook *just* made HTTPS the default:
https://www.facebook.com/notes/facebook-engineering/secure-browsing-by-defau...
As an FYI - facebook, a site where every person is logged in and possibly seeing non-public content is very different than Wikimedia.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Jul 31, 2013 at 6:03 PM, Brian Wolff bawolff@gmail.com wrote:
As for government-run spy networks, we don't know what their full capabilities are. But there are plenty of benefits to rolling out SSL regardless, even just for privacy from the person at the other end of the coffee shop. Firesheep, anyone?
Matt Flaschen
I agree that there's lots of benefits to ssl, and its something that we really should do. I just think we should be clear on our threat model, and not mislead people into thinking it will protect them from an entity with the resources of a state. SSL is too often banded about as being something which will totally prevent government type spying.
--bawolff
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Jul 31, 2013, at 3:12 PM, Magnus Manske magnusmanske@googlemail.com wrote:
There was the lofty notion of including all images, CSS/JS/whatnot as CDATA elements in the page itself, for browsers that support it. That would get around the one issue, but still allow size-based fingerprinting, especially since most users will follow links within the site, so the search space gets much smaller. Random package size increase, as mentioned, might help there.
This is part of why support and rapid adoption of protocols that allow for multiplexing (SPDY/HTTP2.0) are important - they would make the fingerprinting process significantly more difficult.
--Ken.
It was so obvious that int. agencies were doing that. It was discussed in past threads in the mailing list too.
Also, I have read that SSL is not secure neither. So, bleh...
2013/7/31 David Gerard dgerard@gmail.com
Jimmy just tweeted this:
https://twitter.com/jimmy_wales/status/362626509648834560
I think that's the first time I've seen him say "fuck" in a public communication ...
Anyway, I expect people will ask us how the move to all-SSL is progressing. So, how is it going?
(I've been telling people it's slowly moving along, we totally want this, it's just technical resources. But more details would be most useful!)
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 31 July 2013 19:46, Emilio J. Rodríguez-Posada emijrp@gmail.com wrote:
Also, I have read that SSL is not secure neither. So, bleh...
PFS. http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted...
Also, https://en.wikipedia.org/wiki/Nirvana_fallacy - this is somewhere we can in fact do better step by step
- d.
On 31 July 2013 19:48, David Gerard dgerard@gmail.com wrote:
PFS. http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted...
Keeping in mind that PFS is not actually perfect either: http://tonyarcieri.com/imperfect-forward-secrecy-the-coming-cryptocalypse
- d.
On 31 July 2013 19:36, David Gerard dgerard@gmail.com wrote:
Jimmy just tweeted this: https://twitter.com/jimmy_wales/status/362626509648834560 I think that's the first time I've seen him say "fuck" in a public communication ...
And wow, this is the NSA slide that triggered it:
https://image.guim.co.uk/sys-images/Guardian/Pix/audio/video/2013/7/31/13752...
That's us there. Fuck these people.
- d.
Oh - if anyone can authoritatively compose a WMF blog post on the state of the move to SSL (the move to logins and what happened there, the NSA slide, ongoing issues like browsers in China, etc), that would probably be a useful thing :-)
- d.
On Wed, Jul 31, 2013 at 1:06 PM, David Gerard dgerard@gmail.com wrote:
Oh - if anyone can authoritatively compose a WMF blog post on the state of the move to SSL (the move to logins and what happened there, the NSA slide, ongoing issues like browsers in China, etc), that would probably be a useful thing :-)
I'll be posting blog posts each step of the way as we move to SSL. We have plans on SSL for anons by default, but there's no official roadmap for doing so.
- Ryan
Oh - if anyone can authoritatively compose a WMF blog post on the state of the move to SSL (the move to logins and what happened there, the NSA slide, ongoing issues like browsers in China, etc), that would probably be a useful thing :-)
I'll be posting blog posts each step of the way as we move to SSL. We have plans on SSL for anons by default, but there's no official roadmap for doing so.
Something sooner than later might be good. Also have you guys read the presentation. A lot of this is very chilling....
I agree with Jimbo. We need to fix this as best we can.
Thank you, Derric Atzrott
On Wednesday, July 31, 2013, Ryan Lane wrote:
On Wed, Jul 31, 2013 at 1:06 PM, David Gerard <dgerard@gmail.com<javascript:_e({}, 'cvml', 'dgerard@gmail.com');>
wrote:
Oh - if anyone can authoritatively compose a WMF blog post on the state of the move to SSL (the move to logins and what happened there, the NSA slide, ongoing issues like browsers in China, etc), that would probably be a useful thing :-)
I'll be posting blog posts each step of the way as we move to SSL. We have plans on SSL for anons by default, but there's no official roadmap for doing so.
A follow up: I've started writing a blog post about this and hope to have something postable by tomorrow.
- Ryan
It would be useful to focus on the short term problem and solution; the coming quantum computer factoring factory issue which will render large-prime crypto less useful is still on the horizon.
The big threat is lack of basic HTTPS everywhere. The second is site key security (ensuring the NSA never gets your private keys). The third is perfect forward security with rapid key rotation.
George William Herbert Sent from my iPhone
On Jul 31, 2013, at 2:45 PM, Ryan Lane rlane32@gmail.com wrote:
On Wednesday, July 31, 2013, Ryan Lane wrote:
On Wed, Jul 31, 2013 at 1:06 PM, David Gerard <dgerard@gmail.com<javascript:_e({}, 'cvml', 'dgerard@gmail.com');>
wrote:
Oh - if anyone can authoritatively compose a WMF blog post on the state of the move to SSL (the move to logins and what happened there, the NSA slide, ongoing issues like browsers in China, etc), that would probably be a useful thing :-)
I'll be posting blog posts each step of the way as we move to SSL. We have plans on SSL for anons by default, but there's no official roadmap for doing so.
A follow up: I've started writing a blog post about this and hope to have something postable by tomorrow.
- Ryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Jul 31, 2013 at 5:59 PM, George Herbert george.herbert@gmail.comwrote:
The second is site key security (ensuring the NSA never gets your private keys).
Who theoretically has access to the private keys (and/or the signing key) right now?
The third is perfect forward security with rapid key rotation.
Does rapid key rotation in any way make a MITM attack less detectable? Presumably the NSA would have no problem getting a fraudulent certificate signed by DigiCert.
On Wed, Jul 31, 2013 at 9:28 PM, Anthony wikimail@inbox.org wrote:
On Wed, Jul 31, 2013 at 5:59 PM, George Herbert <george.herbert@gmail.com
wrote:
The second is site key security (ensuring the NSA never gets your private keys).
Who theoretically has access to the private keys (and/or the signing key) right now?
People who have root at Wikimedia, which is Wikimedia's operations team and a few of the developers.
The third is perfect forward security with rapid key rotation.
Does rapid key rotation in any way make a MITM attack less detectable? Presumably the NSA would have no problem getting a fraudulent certificate signed by DigiCert.
SSL Observatory would likely pick that up if it was done in any large scale. It's less detectable when done in a targeted way, but if that's the case, the person being targeted is already pretty screwed and we wouldn't likely be the site targeted.
- Ryan
On Thu, Aug 1, 2013 at 4:28 AM, Anthony wikimail@inbox.org wrote:
On Wed, Jul 31, 2013 at 5:59 PM, George Herbert george.herbert@gmail.comwrote:
The second is site key security (ensuring the NSA never gets your private keys).
Who theoretically has access to the private keys (and/or the signing key) right now?
The roots. https://meta.wikimedia.org/wiki/Sysadmins#List (was out of date last time I overhauled it, maybe it's being updated more regularly now)
The third is perfect forward security with rapid key rotation.
Does rapid key rotation in any way make a MITM attack less detectable? Presumably the NSA would have no problem getting a fraudulent certificate signed by DigiCert.
I'm not seeing the relevance. And we have the SSL observatory (EFF) fwiw.
We (society, standards making bodies, etc.) need to do more to reform the current SSL mafia system. (i.e. it should be easier for a vendor to remove a CA from a root store and we shouldn't have a situation where many dozens of orgs all have the ability to sign certs valid for any domain.)
I'm not sure how much we (Wikimedia) can do about that though.
-Jeremy
Le 01/08/13 06:52, Jeremy Baron a écrit :
We (society, standards making bodies, etc.) need to do more to reform the current SSL mafia system. (i.e. it should be easier for a vendor to remove a CA from a root store and we shouldn't have a situation where many dozens of orgs all have the ability to sign certs valid for any domain.)
I'm not sure how much we (Wikimedia) can do about that though.
Potentially similar minded foundations could form a new foundation that would be their SSL authority :-] I am not sure whether it would be cost effective though.
On Thu, Aug 1, 2013 at 9:04 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 01/08/13 06:52, Jeremy Baron a écrit :
We (society, standards making bodies, etc.) need to do more to reform the current SSL mafia system. (i.e. it should be easier for a vendor to remove a CA from a root store and we shouldn't have a situation where many dozens of orgs all have the ability to sign certs valid for any domain.)
I'm not sure how much we (Wikimedia) can do about that though.
Potentially similar minded foundations could form a new foundation that would be their SSL authority :-] I am not sure whether it would be cost effective though.
That would take years of lead time (once the CA is all ready) to get into vendor root stores. And then you have to wait for the products to actually ship.
I guess we could also get cross-signed for the interim. Anyway, would need some long-term vision/investment. That wouldn't help anything until at least the end of next year. But then we still end up with the same problem: dozens of other orgs (in addition to the new hypothetical non-profit) can fraudulently sign a cert for wikipedia and be trusted nearly everywhere.
-Jeremy
On Thu, Aug 1, 2013 at 12:52 AM, Jeremy Baron jeremy@tuxmachine.com wrote:
On Thu, Aug 1, 2013 at 4:28 AM, Anthony wikimail@inbox.org wrote:
Does rapid key rotation in any way make a MITM attack less detectable? Presumably the NSA would have no problem getting a fraudulent certificate signed by DigiCert.
I'm not seeing the relevance. And we have the SSL observatory (EFF) fwiw.
I fully admit that I don't understand exactly how SSL observatory works. I thought it detected when the key changes, so I was wondering whether rapidly rotating keys might thwart that. But again, I don't really understand how it works. So it wasn't a rhetorical question.
We (society, standards making bodies, etc.) need to do more to reform
the current SSL mafia system. (i.e. it should be easier for a vendor to remove a CA from a root store and we shouldn't have a situation where many dozens of orgs all have the ability to sign certs valid for any domain.)
In order to not be easily detected, the cert used by the MITM would need to be from the same CA as the usual one (DigiCert?). Or at least from someone who had obtained DigiCert's key. Or is my cluelessness about how SSL observatory works showing once again?
Antoine Musso hashar+wmf@free.fr wrote:
(ensuring the NSA never gets your private keys)
Which they might already have =)
Or they might get anytime. If I understand it correctly, the NSA didn't steal the root passwords for Google, Facebook and the like, but properly served subpoenas. They could do (or have done) the same for the WMF, provided that the legal requirements are fulfilled.
Enabling SSL for *this* use case is like stocking up ammo for the visit of the tax collector; it doesn't make you tax- exempt, it just means the collection might be a tad more complicated.
Emphasis should be put on that the benefits of HTTPS every- where are primarily against *illegal* snooping.
Tim
wikitech-l@lists.wikimedia.org