On Feb 5, 4:13 pm, Nelson B Bolyard nel...@bolyard.me wrote:
With regard to NSS, I think
that if NSS ignores it, and is found to not adequately facilitate the
implementation of DANE, it may become irrelevant.
Here is a start:
https://mattmccutchen.net/cryptid/#nss-dane
Obviously, this has a
On Jun 22, 1:49 am, Nelson Bolyard nonelsons...@nobolyardspam.me
wrote:
I presume that there must be some incantation that one can give to valgrind
that will force it to shut up about arcfour.
You can write a valgrind suppression, which is essentially a stack
trace pattern that will cause
On Jun 12, 2:25 pm, Nelson B Bolyard nel...@bolyard.me wrote:
On 2010-06-10 22:59 PDT, Robin H. Johnson wrote:
The testcase has been run on Arch and Fedora now, and both of those
cases it works fine.
Does that mean this problem is resolved?
As I read, it is not; it was reported on Gentoo
On May 25, 2:24 pm, Wan-Teh Chang w...@google.com wrote:
On Tue, May 25, 2010 at 11:06 AM, Marsh Ray ma...@extendedsubset.com wrote:
But by that logic, the client should refuse to handshake at all with a
non-RFC-5746 server. (In reality that eventually needs to become the
default behavior).
On May 21, 1:46 am, Kurt Seifried k...@seifried.org wrote:
m...@mattmccutchen.net wrote:
I'm not claiming that the user knows. I only said that if there is in
fact no impersonation, then the error is a false positive.
[...]
For you to claim that the browser should be able to determine the
On Mon, 2010-05-17 at 13:25 -0500, Marsh Ray wrote:
Imagine how fast sites would fix their certs if the scary page proposed
keyword alternative sites that did not have cert issues.
You can't assume that it's the site's fault. A competitor could be
MITM-ing the connection and showing a bad
When
security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref
is off, Firefox will refuse to perform a server-initiated
renegotiation with a non-RFC-5746 server. What is the purpose of this
behavior? It doesn't mitigate the vulnerability because in the attack
scenario, the
On May 19, 11:28 am, Eddy Nigg eddy_n...@startcom.org wrote:
Well, just for the record, lets get this strait - there are no false
positives. I have NEVER encountered an error with a web site and there
was no reason for it. Either the certificate was not trusted or the
domain did not match or
On Fri, 2010-05-21 at 04:02 +0300, Eddy Nigg wrote:
On 05/21/2010 03:23 AM, From Matt McCutchen:
On May 19, 11:28 am, Eddy Niggeddy_n...@startcom.org wrote:
Well, just for the record, lets get this strait - there are no false
positives. I have NEVER encountered an error with a web site
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
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 list is
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 guess
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 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
vulnerability
fixed
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 is
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 Apr 7, 4:54 am, Jean-Marc Desperrier jmd...@gmail.com wrote:
Matt McCutchen wrote:
On Apr 6, 5:54 am, Jean-Marc Desperrierjmd...@gmail.com wrote:
Matt McCutchen wrote:
An extended key usage of TLS Web Server Authentication on the
intermediate CA would constrain all sub
On Apr 3, 9:45 am, Jean-Marc Desperrier jmd...@free.fr 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
On Apr 4, 6:48 am, Eddy Nigg eddy_n...@startcom.org 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
On Apr 7, 12:47 am, Kurt Seifried k...@seifried.org wrote:
What about www.paypal.com[NULL].yourcompany.com? I assume that would
be allowed by the name constraint with respect to fixed software, but
still hit some older software that has the NULL certificate bug.
I think
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
only assume
On Apr 6, 5:54 am, Jean-Marc Desperrier jmd...@gmail.com wrote:
Matt McCutchen wrote:
An extended key usage of TLS Web Server Authentication on the
intermediate CA would constrain all sub-certificates, no?
You are here talking about a proprietary Microsoft extension of the X509
security
On Apr 6, 5:58 am, Jean-Marc Desperrier jmd...@gmail.com wrote:
Ah ! The direction of restricting people who currently use sub-CA for
their purpose to make it more secure will certainly be much more
successful than presenting it as allowing many more people to have their
own sub-CA.
But I do
On Wed, 2010-04-07 at 05:17 +0300, Eddy Nigg wrote:
On 04/07/2010 05:01 AM, Matt McCutchen:
But I do want to allow many more people to have their own sub-CAs,
unless there is an actual technical reason why it is a bad idea, in
which case I am hoping you will tell me.
Yes, for example do
[This thread is to continue the discussion from bug 554442; this
message
recaps the substance of the existing discussion.]
It would be great if a Mozilla-recognized CA would be willing to give
me, as the registrant of mattmccutchen.net, an intermediate CA
certificate with a critical name
On Sat, 2010-04-03 at 23:34 -0700, Nelson B Bolyard wrote:
Let me tell you about one very simple attack. (I think this is old enough
now that the details are no longer big news in the hacking community.) The
MITM has an account on an SMTP server on the same host as an https server.
The SMTP
On Sun, 2010-04-04 at 13:31 +0300, Eddy Nigg wrote:
On 04/04/2010 10:19 AM, Matt McCutchen:
- RFC 4985 section 4 should be clearer that dNSName constraints as such
apply to SRVNames and the SRVName type is only used for constraints that
contain a service name. I may raise that on the pkix
On Sun, 2010-04-04 at 03:19 -0400, Matt McCutchen wrote:
The real problem there is that TLS uses DNS names and thus does not
distinguish different services on the same server. Using RFC 4985
SRVNames such as _SMTP.example.com in certificates would solve that.
I meant to add: Server Name
On Sun, 2010-04-04 at 13:07 +0300, Eddy Nigg wrote:
On 04/04/2010 07:44 AM, Matt McCutchen:
Such configurations are uncommon, but they are not intrinsically
unreasonable. Sites that put parameters in URI path components are
likely to keep the same approach for their write requests
On Sun, 2010-04-04 at 14:06 +0300, Eddy Nigg wrote:
On 04/04/2010 01:49 PM, Matt McCutchen:
Which is simply another user input (modifiable by the user).
That's irrelevant. The Referer is an effective XSRF defense because a
malicious site cannot spoof a Launchpad referrer when
On Apr 4, 6:30 pm, Jean-Marc Desperrier wrote:
On 04/04/2010 08:32, Matt McCutchen wrote:
[...]
It would be great if a Mozilla-recognized CA would be willing to give
me, as the registrant of mattmccutchen.net, an intermediate CA
certificate with a critical name constraint limiting
On Wed, 2010-03-31 at 18:48 +0300, Eddy Nigg wrote:
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
32 matches
Mail list logo
