Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

On Sat, Aug 3, 2013 at 4:19 AM, Ryan Lane wrote: > We're currently have RC4 and AES ciphers in our list, but have RC4 listed > first and have a server preference list to combat BEAST. TLS 1.1/1.2 are > enabled and I'll be adding the GCM ciphers to the beginning of the list > either during Wikiman

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

On Sat, Aug 3, 2013 at 4:19 AM, Ryan Lane wrote: > On Fri, Aug 2, 2013 at 7:23 PM, Anthony wrote: > > It seems that the ciphers which run in CBC mode, at least, are padded. > > Wikipedia currently seems to be set to use RC4 128. I'm not sure what, > if > > any, padding is used by that cipher.

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

On Fri, Aug 2, 2013 at 7:23 PM, Anthony wrote: > On Fri, Aug 2, 2013 at 10:07 PM, Anthony wrote: > > > > > Anthony wrote: > >> > > >> > How much padding is already inherent in HTTPS? > >> > >> None, which is why Ryan's Google Maps fingerprinting example works. > >> > > > > Citation needed. > > >

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

On Fri, Aug 2, 2013 at 11:33 PM, Anthony wrote: > AES and CBC, which would be a block cipher which pads to 128 or 256 bytes. > I mean bits, of course. ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

On Fri, Aug 2, 2013 at 11:09 PM, James Salsman wrote: > Anthony, padding in this context means adding null or random bytes to the > end of encrypted TCP streams in order to obscure their true length. The > process of adding padding is entirely independent of the choice of > underlying cipher. >

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

Anthony, padding in this context means adding null or random bytes to the end of encrypted TCP streams in order to obscure their true length. The process of adding padding is entirely independent of the choice of underlying cipher. In this case, however, we have been discussing perfect forward sec

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

Google also seems to be using RC4 128, so that explains why there's no padding by default there. RC4 is a stream cipher. The more secure ciphers are (all?) block ciphers. "A block cipher works on units of a fixed size

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

> please address https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Padding Sure. As soon as someone creates http://en.wikipedia.org/wiki/Sunset_Shimmerso I can use an appropriate example. ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimed

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

On Fri, Aug 2, 2013 at 10:07 PM, Anthony wrote: > > Anthony wrote: >> > >> > How much padding is already inherent in HTTPS? >> >> None, which is why Ryan's Google Maps fingerprinting example works. >> > > Citation needed. > Also please address https://en.wikipedia.org/wiki/Block_cipher_modes_of_

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

> Anthony wrote: > > > > How much padding is already inherent in HTTPS? > > None, which is why Ryan's Google Maps fingerprinting example works. > Citation needed. > >... Seems to me that any amount of padding is going to give little > > bang for the buck > > Again, can we please procure expe

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

Marc A. Pelletier wrote: >... >> http://www.ieee-security.org/TC/SP2012/papers/4681a332.pdf >... > have you actually /read/ that paper? Of course I have. Have you read the conclusions at the bottom right of page 344? What kind of an adversary trying to infer our readers' article selections is goin

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

On 08/02/2013 08:15 PM, James Salsman wrote: > No, that is not true, and > http://www.ieee-security.org/TC/SP2012/papers/4681a332.pdf > explains why. Padding makes it difficult but not impossible to distinguish > between two HTTPS destinations. 4,300,000 destinations is right out. ... have you act

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

>... random padding without (at least) pipelining and > placards *is* worthless to protect against traffic analysis No, that is not true, and http://www.ieee-security.org/TC/SP2012/papers/4681a332.pdf explains why. Padding makes it difficult but not impossible to distinguish between two HTTPS dest

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

On 08/02/2013 05:50 PM, Matthew Flaschen wrote: > It seems from the context "better tested" meant something like "people > are using this in practice in real environments", not only automated > testing. And, indeed, given the constraints and objectives of the Tool Labs (i.e.: no secrecy, all open

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

On 08/02/2013 05:06 PM, James Salsman wrote: > Marc, I note that you have recommending not keeping the Perl CPAN > modules up to date on Wikimedia Labs: > http://www.mediawiki.org/w/index.php?title=Wikimedia_Labs/Tool_Labs/Needed_Toolserver_features&diff=678902&oldid=678746 > saying that out of dat

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

Marc A. Pelletier wrote: >... > A minor random increase of size in document wouldn't even slow > down [fingerprinting.] That's absolutely false. The last time I measured the sizes of all 9,625 vital articles, there was only one at the median length of 30,356 bytes but four articles up to 50 bytes

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

How much padding is already inherent in HTTPS? Does the protocol pad to the size of the blocks in the block cipher? Seems to me that any amount of padding is going to give little bang for the buck, at least without using some sort of pipelining. You could probably do quite a bit if you redesigne

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

On 08/02/2013 01:32 PM, James Salsman wrote: > Padding each transmission with a random number of bytes, up to say 50 > or 100, might provide a greater defense against fingerprinting while > saving massive amounts of bandwidth. It would slightly change the algorithm used to make the fingerprint, no

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

On Fri, Aug 2, 2013 at 1:32 PM, James Salsman wrote: > George William Herbert wrote: > >... > > It would also not be much more effort or customer impact > > to pad to the next larger 1k size for a random large fraction > > of transmissions. > > Padding each transmission with a random number of by

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

George William Herbert wrote: >... > It would also not be much more effort or customer impact > to pad to the next larger 1k size for a random large fraction > of transmissions. Padding each transmission with a random number of bytes, up to say 50 or 100, might provide a greater defense against fi

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

On Aug 1, 2013, at 10:07 PM, Ryan Lane wrote: > Also, > our resources are delivered from a number of urls (upload, bits, text) > making it easier to identify resources. Even with padding you can take the > relative size of resources being delivered, and the order of those sizes > and get a pre

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

On Thursday, August 1, 2013, James Salsman wrote: > Ryan Lane wrote: > >... > > Assuming traffic analysis can be used to determine your browsing > > habits as they are occurring (which is likely not terribly hard for > Wikipedia) > > The Google Maps example you linked to works by building a huge >

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

Ryan Lane wrote: >... > Assuming traffic analysis can be used to determine your browsing > habits as they are occurring (which is likely not terribly hard for Wikipedia) The Google Maps example you linked to works by building a huge database of the exact byte sizes of satellite image tiles. Are yo

Re: [Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

On Thu, Aug 1, 2013 at 1:33 PM, James Salsman wrote: > With the NSA revelations over the past months, there has been some very > questionable information starting to circulate suggesting that trying to > implement perfect forward secrecy for https web traffic isn't worth the > effort. I am not su

[Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

With the NSA revelations over the past months, there has been some very questionable information starting to circulate suggesting that trying to implement perfect forward secrecy for https web traffic isn't worth the effort. I am not sure of the provenance of these reports, and I would like to see