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

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

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

Anthony-73
On Fri, Aug 2, 2013 at 11:09 PM, James Salsman <[hidden email]> 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.
>

My point is that if the stream is encrypted using a block cipher (at least,
in CBC mode), then it's already padded to the block size of the cipher.

That's the more complete answer to my question of "How much padding is
already inherent in HTTPS?"  HTTPS itself does not have any inherent
padding, but when used with certain block ciphers, it does.

By the way, for most hours it's around 2.1-2.3 million, not 4.3 million.
 Wikimedia has been kind enough to give us a list of which pages are viewed
each hour of the day, along with the size of each page:
http://dumps.wikimedia.org/other/pagecounts-raw/

In this case, however, we have been discussing perfect forward secrecy,
> which is dependent on the particular cypher. ECDHE-RSA-RC4-SHA is an
> example of a PFS cipher and TLS key exchange protocol choice widely
> supported by Apache supporting PFS.
>

PFS is the method of key exchange.  You can use it with various different
ciphers.  From what I'm reading it can be used with AES and CBC, which
would be a block cipher which pads to 128 or 256 bytes.
_______________________________________________
Wikimedia-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Anthony-73
On Fri, Aug 2, 2013 at 11:33 PM, Anthony <[hidden email]> 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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Ryan Lane-3
In reply to this post by Anthony-73
On Fri, Aug 2, 2013 at 7:23 PM, Anthony <[hidden email]> wrote:

> On Fri, Aug 2, 2013 at 10:07 PM, Anthony <[hidden email]> 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_operation#Padding
>
> 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.  But presumably Wikipedia will switch
> to a better cipher if Wikimedia cares about security.
>

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 Wikimania or as soon as I get back.

- Ryan
_______________________________________________
Wikimedia-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Anthony-73
On Sat, Aug 3, 2013 at 4:19 AM, Ryan Lane <[hidden email]> wrote:

> On Fri, Aug 2, 2013 at 7:23 PM, Anthony <[hidden email]> 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.  But presumably Wikipedia will
> switch
> > to a better cipher if Wikimedia cares about security.
> >
>
> 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 Wikimania or as soon as I get back.
>

Rereading that it looks like I might have implied that Wikimedia didn't
care about security.  That was absolutely not my intended implication.
 Sorry about that.
_______________________________________________
Wikimedia-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Tyler Romeo
In reply to this post by Ryan Lane-3
On Sat, Aug 3, 2013 at 4:19 AM, Ryan Lane <[hidden email]> 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 Wikimania or as soon as I get back
>

If possible, could a quick announcement be made (either here or on wikitech
or on bug 52496), when we start supporting GCM? Much appreciated.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | [hidden email]
_______________________________________________
Wikimedia-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
12