On Mon, 2010-04-19 at 14:00 -0700, Robert Relyea wrote:
> > It's not going to look so great for Mozilla when another prominent
> > browser vendor ships another patch which also notifies the user of the
> > insecure connection.
> >
> Mozilla is phasing in, just like Opera. You can see some in the
On Mon, 2010-04-19 at 15:10 -0500, Marsh Ray wrote:
> > Direct your energy at the problem you want to solve. Talk to some server
> > admins. Ask them why they are reluctant to take action. Find some real
> > industry representatives. Ask for their help. The first thing they need
> > from you is a c
On 2010/04/19 11:32 PDT, johnjbarton wrote:
> On 4/19/2010 10:52 AM, Nelson B Bolyard wrote:
>> On 2010/04/19 08:33 PDT, johnjbarton wrote:
>>> The browser's legitimate role here informs users on the connection they
>>> have to a server. If Firefox is presenting a user interface that shows
>>> a s
On 04/19/2010 12:33 PM, Marsh Ray wrote:
>
> Opera will currently decline to turn the address bar green for EV certs
> if the connection is vulnerable. That is a great first step, and they
> intend to make that more prominent over time, too.
>
That's an interesting option
> Mozilla also has
On 4/19/2010 1:32 PM, johnjbarton wrote:
> On 4/19/2010 10:52 AM, Nelson B Bolyard wrote:
>>
>> The industry is largely sticking its head in the sand, saying "don't
>> bother
>> me with the facts, don't give me errors or warnings. I'd rather be
>> ignorant of this huge security hole (and keep my u
On 4/19/2010 12:52 PM, Nelson B Bolyard wrote:
> On 2010/04/19 08:33 PDT, johnjbarton wrote:
>> The legitimate action by browser developers is to fix their bug.
>
> But that, by itself, does not provide the users with transport security.
Right, both the client and server have to be patched. It's
On 4/19/2010 10:52 AM, Nelson B Bolyard wrote:
On 2010/04/19 08:33 PDT, johnjbarton wrote:
...
There are appropriate channels for advertising this problem and
educating users and servers about it. The current Error Console spam
campaign and the propose pop-up ads campaign are simply not appr
On 2010/04/19 08:33 PDT, johnjbarton wrote:
> On 4/19/2010 1:42 AM, Nelson B Bolyard wrote:
>> On 2010-04-18 21:16 PST, johnjbarton wrote:
>>
>>> I see nothing wrong with users contacting sysadmins. I object to
>>> using the browser as a platform for badgering Web developers to
>>> contact sysadmi
On 4/19/2010 1:42 AM, Nelson B Bolyard wrote:
On 2010-04-18 21:16 PST, johnjbarton wrote:
I see nothing wrong with users contacting sysadmins. I object to using
the browser as a platform for badgering Web developers to contact
sysadmins on your behalf.
You continue to make the mistake of assu
On 2010-04-18 21:16 PST, johnjbarton wrote:
> I see nothing wrong with users contacting sysadmins. I object to using
> the browser as a platform for badgering Web developers to contact
> sysadmins on your behalf.
You continue to make the mistake of assuming that users have no vested self
intere
On 4/18/2010 10:36 AM, Matt McCutchen wrote:
On Sat, 2010-04-10 at 08:10 -0700, johnjbarton wrote:
On 4/9/2010 6:06 PM, Matt McCutchen wrote:
Are you saying that Mozilla shouldn't encourage users to bother their
server operators because if the problem were real, the server operators
would alrea
On Sat, 2010-04-10 at 08:10 -0700, johnjbarton wrote:
> On 4/9/2010 6:06 PM, Matt McCutchen wrote:
> > Are you saying that Mozilla shouldn't encourage users to bother their
> > server operators because if the problem were real, the server operators
> > would already have fixed it? I think you give
On Fri, 2010-04-09 at 02:45 +0200, Kai Engert wrote:
> On 09.04.2010 00:41, Matt McCutchen wrote:
> > On Thu, 2010-04-08 at 09:59 -0700, Robert Relyea wrote:
> >> The yellow larry is a good proposal, and probably implementable much
> >> sooner than noisy warnings.
> >
> > I'm glad you like it. I g
On 4/14/2010 7:51 PM, Eddy Nigg wrote:
>
> It might be possible for the clients to ping the server if renegotiation
> (in old way) is supported at all. There are quite some servers out there
> that don't do that by default. With this, the pain could be perhaps
> mitigated.
> The claim was made her
On 04/14/2010 02:58 AM, Marsh Ray:
Here are some excerpts from http://tools.ietf.org/html/rfc5746
I tried to cut out some of the irrelevant details so as not to
"desensitize" everybody with too much information :-)
Thanks for your response here...
So the RFC RECOMMENDED many times against
> Well, I think a client that doesn't implement RFC 5746 can't do
> renegotiation with a server that implements RFC 5746 and vice versa.
In coming up with the wording of RFC 5746 we wanted to spell out what it
would take to restore the (stated and implied) integrity guarantees
offered by SSL/TLS
On 12/04/2010 15:29, Eddy Nigg wrote:
updated servers need updates clients and break older ones, whereas old
servers will not allow new clients.
I haven't seen one yet, that doesn't have a flag to accept older
clients. If you set that flag, *and* disable renegotiation at least
for older clien
On 12/04/2010 15:29, Eddy Nigg wrote:
updated servers need updates clients and break older ones, whereas old
servers will not allow new clients.
I haven't seen one yet, that doesn't have a flag to accept older
clients. If you set that flag, *and* disable renegotiation at least for
older clien
On 04/12/2010 05:48 AM, Nelson Bolyard:
.. The warnings will come --
WHEN? In 2010? In 2011?
Whenever it will be, it will become an entire mess. That's because
updated servers need updates clients and break older ones, whereas old
servers will not allow new clients.
Basically i
On 4/11/2010 7:48 PM, Nelson Bolyard wrote:
On 2010-04-08 09:59 PST, Robert Relyea wrote:
On 04/07/2010 09:35 PM, Nelson B Bolyard wrote:
We plan on alerting users in a future update. This is fair warning
to server operators and those who are debugging their sites.
If this is a real threat do
On 2010-04-08 09:59 PST, Robert Relyea wrote:
> On 04/07/2010 09:35 PM, Nelson B Bolyard wrote:
> We plan on alerting users in a future update. This is fair warning
> to server operators and those who are debugging their sites.
>
If this is a real threat don't users deser
On 4/9/2010 6:06 PM, Matt McCutchen wrote:
On Fri, 2010-04-09 at 09:34 -0700, johnjbarton wrote:
On 4/8/2010 12:13 PM, Matt McCutchen wrote:
On Thu, 2010-04-08 at 09:35 -0700, johnjbarton wrote:
On 4/7/2010 9:35 PM, Nelson B Bolyard wrote:
...
Inconveniencing the users is a NECESSARY part of
On Fri, 2010-04-09 at 09:34 -0700, johnjbarton wrote:
> On 4/8/2010 12:13 PM, Matt McCutchen wrote:
> > On Thu, 2010-04-08 at 09:35 -0700, johnjbarton wrote:
> >> On 4/7/2010 9:35 PM, Nelson B Bolyard wrote:
> >> ...
> >>> Inconveniencing the users is a NECESSARY part of getting this
> >>> vulnera
On 4/8/2010 12:13 PM, Matt McCutchen wrote:
On Thu, 2010-04-08 at 09:35 -0700, johnjbarton wrote:
On 4/7/2010 9:35 PM, Nelson B Bolyard wrote:
...
Inconveniencing the users is a NECESSARY part of getting this vulnerability
fixed. Without that, the servers have NO INCENTIVE to lift a finger to
On 09.04.2010 00:41, Matt McCutchen wrote:
On Thu, 2010-04-08 at 09:59 -0700, Robert Relyea wrote:
The yellow larry is a good proposal, and probably implementable much
sooner than noisy warnings.
I'm glad you like it. I guess the next thing needed is for someone to
actually implement it, perh
On Thu, 2010-04-08 at 09:59 -0700, Robert Relyea wrote:
> The yellow larry is a good proposal, and probably implementable much
> sooner than noisy warnings.
I'm glad you like it. I guess the next thing needed is for someone to
actually implement it, perhaps me if I can figure out how.
--
Matt
On 2010/04/08 09:35 PDT, johnjbarton wrote:
> On 4/7/2010 9:35 PM, Nelson B Bolyard wrote: ...
>> Inconveniencing the users is a NECESSARY part of getting this
>> vulnerability fixed. Without that, the servers have NO INCENTIVE to
>> lift a finger to fix this.
> ...
>
> The claim is obviously fal
On Thu, 2010-04-08 at 09:35 -0700, johnjbarton wrote:
> On 4/7/2010 9:35 PM, Nelson B Bolyard wrote:
> ...
> > Inconveniencing the users is a NECESSARY part of getting this vulnerability
> > fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix
> > this.
> ...
>
> The claim i
On 04/07/2010 09:35 PM, Nelson B Bolyard wrote:
>
We plan on alerting users in a future update. This is fair warning
to server operators and those who are debugging their sites.
>>> If this is a real threat don't users deserve a fair warning now?
>>>
>> I fully agree
On 4/7/2010 9:35 PM, Nelson B Bolyard wrote:
...
Inconveniencing the users is a NECESSARY part of getting this vulnerability
fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix
this.
...
The claim is obviously false as the recent update to Firefox 3.6.3
clearly demonstr
On 2010/04/07 10:43 PDT, Matt McCutchen wrote:
> On Wed, 2010-04-07 at 09:55 -0700, johnjbarton wrote:
>> On 4/4/2010 10:41 PM, Daniel Veditz wrote:
>>> We plan on alerting users in a future update. This is fair warning
>>> to server operators and those who are debugging their sites.
>>
>> If th
On Wed, 2010-04-07 at 09:55 -0700, johnjbarton wrote:
> On 4/4/2010 10:41 PM, Daniel Veditz wrote:
> > On 4/3/10 9:30 AM, johnjbarton wrote:
> >> If the *users* of Firefox are truly in jeopardy, then this alert should
> >> be provided to *users*. Since this alert is not shown to users I can
> >> on
On 4/4/2010 10:41 PM, Daniel Veditz wrote:
On 4/3/10 9:30 AM, johnjbarton wrote:
If the *users* of Firefox are truly in jeopardy, then this alert should
be provided to *users*. Since this alert is not shown to users I can
only assume that in fact there is no practical threat here. You're
putting
On Apr 4, 6:48 am, Eddy Nigg wrote:
> It's trivial from the logical point of view.
That's easy for you to say. Even things that are logically trivial
are easy to miss unless one goes carefully over every single step of
the process. For instance, I used a little script to check
certificates agai
On Apr 3, 9:45 am, Jean-Marc Desperrier wrote:
> It's the sites that need to catch on those updates.
> And web developers can have power to influence those sites to update.
FWIW, I am a DreamHost customer and I just submitted a support ticket
with them to close the vulnerability for customer site
On 4/3/10 9:30 AM, johnjbarton wrote:
> If the *users* of Firefox are truly in jeopardy, then this alert should
> be provided to *users*. Since this alert is not shown to users I can
> only assume that in fact there is no practical threat here. You're
> putting this message in the Error Console bec
On 04/04/2010 09:34 AM, Nelson B Bolyard:
It's not so trivial.
It's trivial from the logical point of view.
I did wonder about this once or twice over 13 years, but didn't
see any way to exploit it and so I thought it was safe. Someone finally
found a way. Thank goodness Marsh Ray wears a w
On 2010-04-03 04:29 PST, Eddy Nigg wrote:
> On 04/03/2010 01:07 PM, Nelson B Bolyard:
>> This is true because the attacker can arrange it so that the victim
>> client's first handshake is actually a renegotiation for the server.
>> It's NOT a renegotiation for the client, but it IS for the server
On 4/3/2010 6:45 AM, Jean-Marc Desperrier wrote:
On 02/04/2010 18:25, johnjbarton wrote:
The appropriate way to address this security problem starts by
contacting the major providers of server software
There's no need to contact them, they are well aware of the problem.
AFAIK they have all alr
On 02/04/2010 18:25, johnjbarton wrote:
The appropriate way to address this security problem starts by
contacting the major providers of server software
There's no need to contact them, they are well aware of the problem.
AFAIK they have all already issued the necessary updates.
It's the sites
On 04/03/2010 01:07 PM, Nelson B Bolyard:
This is true because the attacker can arrange it so that the victim client's
first handshake is actually a renegotiation for the server.
It's NOT a renegotiation for the client, but it IS for the server.
The server has previously negotiated with the attac
On 2010-04-02 14:06 PST, Eddy Nigg wrote:
> Hi Bob,
>
> On 04/02/2010 01:34 AM, Robert Relyea:
>>> When a client (as in our case Firefox) implements RFC 5746, the
>>> client can't be compromised and no data is leaked from the client. I
>>> propose that Firefox should support the RFC 5746 extensi
Hi Bob,
On 04/02/2010 01:34 AM, Robert Relyea:
When a client (as in our case Firefox) implements RFC 5746, the
client can't be compromised and no data is leaked from the client. I
propose that Firefox should support the RFC 5746 extension
exclusively, but NOT block or warn on accessing serve
On 4/2/2010 2:22 AM, Jean-Marc Desperrier wrote:
johnjbarton wrote:
Closely related to bug 554594 is
https://bugzilla.mozilla.org/show_bug.cgi?id=535649
Web developers using Firefox Error Console or tools like Firebug that
use nsIConsoleService are now bombarded with pointless messages like:
s
On 04/02/2010 01:37 AM, Daniel Veditz:
SSL is a
building-block and is supposed to guarantee an authenticated,
encrypted, tamper-proof connection to the application layers above.
Yes, obviously I agree with this statement entirely and RFC 5746 fixes that.
You don't know that! Depends on wh
johnjbarton wrote:
Closely related to bug 554594 is
https://bugzilla.mozilla.org/show_bug.cgi?id=535649
Web developers using Firefox Error Console or tools like Firebug that
use nsIConsoleService are now bombarded with pointless messages like:
services.addons.mozilla.org : potentially vulnerabl
On 3/31/10 5:26 AM, Eddy Nigg wrote:
> security.ssl.require_safe_negotiation
>
> I believe this to be a mistake for various reasons, but first and
> foremost because an attack on a server without compromise of the client
> data as well, is basically useless. When a attacker induces
> ren
On 03/31/2010 05:26 AM, Eddy Nigg wrote:
> [ Please follow up to mozilla.dev.tech.crypto ]
>
> After some discussion at bug 554594 I'm following up here - the bug
> was unfortunately misused by me a little for the initial discussion.
>
> At https://wiki.mozilla.org/Security:Renegotiation under item
On 03/31/2010 06:48 PM, Eddy Nigg:
On 03/31/2010 04:45 PM, Kai Engert:
== snip quote begin ==
E.g., the attacker would send:
GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
X-Ignore-This:
And the server uses the victim's account to send a pizza to the
attacker.
==
On 03/31/2010 04:45 PM, Kai Engert:
== snip quote begin ==
E.g., the attacker would send:
GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
X-Ignore-This:
And the server uses the victim's account to send a pizza to the attacker.
=== snip quote end ===
This attack
On 3/31/2010 5:26 AM, Eddy Nigg wrote:
[ Please follow up to mozilla.dev.tech.crypto ]
After some discussion at bug 554594 I'm following up here - the bug was
unfortunately misused by me a little for the initial discussion.
Closely related to bug 554594 is
https://bugzilla.mozilla.org/show_bug
On 31.03.2010 14:26, Eddy Nigg wrote:
[ Please follow up to mozilla.dev.tech.crypto ]
After some discussion at bug 554594 I'm following up here - the bug was
unfortunately misused by me a little for the initial discussion.
At https://wiki.mozilla.org/Security:Renegotiation under item 4.4 the
[ Please follow up to mozilla.dev.tech.crypto ]
After some discussion at bug 554594 I'm following up here - the bug was
unfortunately misused by me a little for the initial discussion.
At https://wiki.mozilla.org/Security:Renegotiation under item 4.4 the
following is proposed:
sec
53 matches
Mail list logo
