The important thing to realize is that intermediaries look at, and can
be confused by, traffic destined to the attacker's servers. That's
why it's important to mask attacker-controlled data on the wire.
Adam
On Thu, Mar 24, 2011 at 10:20 AM, Matthew Kaufman wrote:
> On 3/24/2011 12:44 AM, Adam
On 3/24/2011 12:44 AM, Adam Barth wrote:
Our experience with WebSockets indicates that masking is still
important even when communicating between the browser and an
attacker-controlled server. The problem is that intermediaries
attempt to "sniff" the protocol by looking at the bytes on the wir
On Wed, Mar 23, 2011 at 4:06 PM, Glenn Maynard wrote:
> On Wed, Mar 23, 2011 at 6:25 PM, Harald Alvestrand
> wrote:
>> The STUN server is used to obtain your own "public" IP address, for
>> constructing candidate lists.
>> The STUN server is not involved in the ICE handshake.
>
> The STUN server
On 3/23/2011 5:22 PM, Harald Alvestrand wrote:
On 03/24/11 01:13, Matthew Kaufman wrote:
On 3/23/2011 3:17 PM, Harald Alvestrand wrote:
Is there really an advantage to not using SRTP and reusing the RTP
format for the data messages?
I'd go one further... why not DTLS-SRTP for the media and DT
On 3/23/2011 3:57 PM, Harald Alvestrand wrote:
I don't think such an attack is possible; there is no mechanism in ICE
for changing the destination IP address without a new handshake.
The potential attack we can't avoid is that a hostile webapp, possibly
with the help of a hostile STUN server
On 03/24/11 01:13, Matthew Kaufman wrote:
On 3/23/2011 3:17 PM, Harald Alvestrand wrote:
Is there really an advantage to not using SRTP and reusing the RTP
format for the data messages?
I'd go one further... why not DTLS-SRTP for the media and DTLS with
some other header shim for the data mes
On 3/23/2011 3:17 PM, Harald Alvestrand wrote:
Is there really an advantage to not using SRTP and reusing the RTP
format for the data messages?
I'd go one further... why not DTLS-SRTP for the media and DTLS with some
other header shim for the data messages?
In particular, there are significa
On Wed, Mar 23, 2011 at 6:25 PM, Harald Alvestrand wrote:
> The STUN server is used to obtain your own "public" IP address, for
> constructing candidate lists.
> The STUN server is not involved in the ICE handshake.
>
The STUN server is not. I believe the STUN *protocol* (packet format),
however
On 03/23/11 23:43, Ian Hickson wrote:
On Wed, 23 Mar 2011, Harald Alvestrand wrote:
On 03/18/11 21:19, Glenn Maynard wrote:
On Thu, Mar 17, 2011 at 9:28 PM, Adam Barth wrote:
So, the salt and the nonce play different roles. The salt is to make
sure the message appears random if you haven't
On Wed, 23 Mar 2011, Harald Alvestrand wrote:
> On 03/18/11 21:19, Glenn Maynard wrote:
> > On Thu, Mar 17, 2011 at 9:28 PM, Adam Barth wrote:
> >
> > > So, the salt and the nonce play different roles. The salt is to make
> > > sure the message appears random if you haven't read the spec (and so
On 03/18/11 21:19, Glenn Maynard wrote:
On Thu, Mar 17, 2011 at 9:28 PM, Adam Barth wrote:
So, the salt and the nonce play different roles. The salt is to make
sure the message appears random if you haven't read the spec (and so
don't know the salt). The nonce is to prevent the attacker from
Is there really an advantage to not using SRTP and reusing the RTP
format for the data messages?
This is a well-known and well-analyzed encryption format, with
reasonably known security properties and library support (from libraries
that already have to be included in order to support audio/vide
On Fri, Mar 18, 2011 at 11:28 PM, Ian Hickson wrote:
> The other ICE peer, the STUN server, the TURN server (if any), and the
> signaling channel are all under the control of the attacker in a worst
> case scenario (the user being directed to a hostile or hijacked site). The
> attacker essentiall
On Fri, 18 Mar 2011, Glenn Maynard wrote:
>
> It's possible that ICE doesn't actually negotiate this securely, since
> the STUN server itself is untrusted. Do you (or anyone else) know if
> STUN negotiation is secure under these circumstances? Or do you think
> it doesn't matter?
The other I
On Thu, Mar 17, 2011 at 9:28 PM, Adam Barth wrote:
> So, the salt and the nonce play different roles. The salt is to make
> sure the message appears random if you haven't read the spec (and so
> don't know the salt). The nonce is to prevent the attacker from
> crafting plaintexts that encrypt t
On Thu, Mar 17, 2011 at 9:24 PM, Glenn Maynard wrote:
> On Thu, Mar 17, 2011 at 11:07 PM, Adam Barth wrote:
>>> But you get this with a per-connection (not per-packet) nonce and CTR's
>>> sequence number. You don't need a unique 16-byte nonce for each packet.
>>
>> The attacker observes each pac
On Thu, Mar 17, 2011 at 11:07 PM, Adam Barth wrote:
>> But you get this with a per-connection (not per-packet) nonce and CTR's
>> sequence number. You don't need a unique 16-byte nonce for each packet.
>
> The attacker observes each packet once delivered, so you need a new
> nonce for each packet
On Thu, Mar 17, 2011 at 7:51 PM, Glenn Maynard wrote:
> On Thu, Mar 17, 2011 at 9:28 PM, Adam Barth wrote:
>> So, the salt and the nonce play different roles. The salt is to make
>> sure the message appears random if you haven't read the spec (and so
>> don't know the salt). The nonce is to pre
On Thu, Mar 17, 2011 at 9:28 PM, Adam Barth wrote:
> So, the salt and the nonce play different roles. The salt is to make
> sure the message appears random if you haven't read the spec (and so
> don't know the salt). The nonce is to prevent the attacker from
> crafting plaintexts that encrypt t
On Thu, Mar 17, 2011 at 6:21 PM, Glenn Maynard wrote:
> On Thu, Mar 17, 2011 at 8:06 PM, Adam Barth wrote:
>> The encryption serves two purposes. First, it provides
>> confidentiality from eavesdroppers, as you appear to be aware.
>> Second, it provides a defense against cross-protocol attacks,
On Thu, Mar 17, 2011 at 8:06 PM, Adam Barth wrote:
> The encryption serves two purposes. First, it provides
> confidentiality from eavesdroppers, as you appear to be aware.
> Second, it provides a defense against cross-protocol attacks, which is
> why the salt and the per-message nonce are impor
Hi Glenn,
The encryption serves two purposes. First, it provides
confidentiality from eavesdroppers, as you appear to be aware.
Second, it provides a defense against cross-protocol attacks, which is
why the salt and the per-message nonce are important.
Theoretically, we could just use an initial
PeerConnection defines packet encryption, but it uses AES-128-CTR
without actually defining the counter. It also generates a new AES
key for each packet. A major point of using CTR is to not have to do
that; you have a single key and vary the counter.
The inputs to AES-128-CTR are a key, a count
23 matches
Mail list logo
