On 03/03/09 14:30, Jean-Marc Desperrier wrote:
What about a white version of the hostname display for http sites ?
Because it's not reliable information due to MITM. And trying to tell
users white means don't trust it, blue or green means do trust it is
far harder than trust it if it's
Florian Weimer wrote:
Most users are not subject to MITM attacks
This may or may not be true given the prevalence of wireless networks
out there... we've had a number of reports of in-the-wild MITM attacks
by wireless network operators.
but they do receive all kinds of URL lures.
Yes,
On 03/04/2009 03:36 PM, Boris Zbarsky:
Florian Weimer wrote:
Most users are not subject to MITM attacks
This may or may not be true given the prevalence of wireless networks
out there... we've had a number of reports of in-the-wild MITM attacks
by wireless network operators.
Yes, many
Eddy Nigg wrote:
[...] When do we expect SSL? On submit or on
password fields in a form[...]
IF page contains form
AND form contains password field
THEN flash insecure form warning
Could be done. But there would better be a cross browser agreement on
this. And coupled with a way to offer
On 4-Mar-09, at 8:36 AM, Boris Zbarsky wrote:
Florian Weimer wrote:
Most users are not subject to MITM attacks
This may or may not be true given the prevalence of wireless
networks out there... we've had a number of reports of in-the-wild
MITM attacks by wireless network operators.
On 03/04/2009 04:18 PM, Jean-Marc Desperrier:
Eddy Nigg wrote:
[...] When do we expect SSL? On submit or on
password fields in a form[...]
IF page contains form
AND form contains password field
THEN flash insecure form warning
Could be done. But there would better be a cross browser
On 03/04/2009 04:28 PM, Johnathan Nightingale:
no website can spoof the EV appearance of the site identity
button and, with the ssl_domain_display pref set to non-zero, (and
appropriate care given to IDN issues), they can't for regular SSL either.
Right, and I'm extremely glad that we are
This kind of thing?
https://addons.mozilla.org/en-US/firefox/addon/8128
On 4-Mar-09, at 9:42 AM, Eddy Nigg wrote:
On 03/04/2009 04:28 PM, Johnathan Nightingale:
no website can spoof the EV appearance of the site identity
button and, with the ssl_domain_display pref set to non-zero, (and
On 03/04/2009 04:48 PM, Johnathan Nightingale:
This kind of thing?
https://addons.mozilla.org/en-US/firefox/addon/8128
It looks nice! I think it should also turn red if the starting page is
unsecured, not only the landing page, but technically this would not be
correct. However I'd fee
Gervase Markham wrote:
[...]
We just turned hostname display UI for SSL on, according to The Burning
Edge...
This is a nice change, I found out about it on the burning edge too :-)
But, and as the link Eddy just reported shows, the attack is far from
being only for SSL.
I think we should
On 03/03/2009 04:30 PM, Jean-Marc Desperrier:
But, and as the link Eddy just reported shows, the attack is far from
being only for SSL.
I think we should reconsider the options available to make the domain
name more visible for http connexions.
What about a white version of the hostname display
Jean-Marc Desperrier wrote:
But, and as the link Eddy just reported shows, the attack is far from
being only for SSL.
I think we should reconsider the options available to make the domain
name more visible for http connexions.
What about a white version of the hostname display for http sites
Boris Zbarsky wrote:
Jean-Marc Desperrier wrote:
But, and as the link Eddy just reported shows, the attack is far from
being only for SSL.
I think we should reconsider the options available to make the domain
name more visible for http connexions.
What about a white version of the hostname
On 03/03/2009 05:51 PM, Boris Zbarsky:
Jean-Marc Desperrier wrote:
But, and as the link Eddy just reported shows, the attack is far from
being only for SSL.
I think we should reconsider the options available to make the domain
name more visible for http connexions.
What about a white version
On 27/02/09 14:48, Boris Zbarsky wrote:
It's not clear to me that the person who added the list even knew the
page existed.
Neil added the list, and he wrote the second half of the page. So there
was mutual knowledge. The list isn't documented on the page because,
strictly speaking, it's not
Subject was [Fwd: Facebook message - Received Messages Quickly]
I've received it a few minutes ago. The URL doesn't us SSL, but it shows
exactly what I posted in this thread not long ago...see forwarded
message below:
Regards
Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org/
Boris Zbarsky wrote:
Jean-Marc Desperrier wrote:
Which blacklist ? There's a blacklist inside the browser ?
Yes. See
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/libpref/src/init/all.jsrev=3.762mark=704-708#704
I'm left with the feeling this really should have been more
Jean-Marc Desperrier wrote:
I'm left with the feeling this really should have been more widely
documented.
Could be!
The existence of that protection was really hard to guess from the
tld-idn-policy-list.html page :
It's not clear to me that the person who added the list even knew the
Paul Hoffman wrote:
At 7:09 AM +0100 2/24/09, Kaspar Brand wrote:
Kyle Hamilton wrote:
Removal of support for wildcards can't be done without PKIX action, if
one wants to claim conformance to RFC 3280/5280.
Huh? Both these RFCs completely step out of the way when it comes to
wildcard
On 02/26/2009 01:49 PM, Jean-Marc Desperrier:
Just one thing : The use of a wildcard certificate was a misleading red
herring in the implementation of the attack.
Yes, I've been saying it all along.
What's truly broken is that the current i18n attack protection relies on
the checking done
On 26/02/09 11:49, Jean-Marc Desperrier wrote:
What's truly broken is that the current i18n attack protection relies on
the checking done by the registrar/IDN, and that the registrar/IDN can
only check the second-level domain name component.
Actually, our protection had a bug (that is, there
Gervase Markham wrote:
On 26/02/09 11:49, Jean-Marc Desperrier wrote:
What's truly broken is that the current i18n attack protection relies on
the checking done by the registrar/IDN, and that the registrar/IDN can
only check the second-level domain name component.
Actually, our protection had
Jean-Marc Desperrier wrote:
Which blacklist ? There's a blacklist inside the browser ?
Yes. See
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/libpref/src/init/all.jsrev=3.762mark=704-708#704
The oppposite seems obviously said here :
Nelson Bolyard wrote:
[...]
Wildcards are not an essential part of this attack. They merely were a
convenience for this demonstration, but the attack could have been done
without using a wildcard cert. Even eliminating wildcard certs altogether
would not stop this attack.
This being said :
On 02/23/2009 02:35 PM, Jean-Marc Desperrier:
- I don't expect there will be any effort to try to stop CA from issuing
dangerous wildcard certificates, since it won't solve the problem at large.
This isn't the cure of the problem, wild cards are very useful! The
problem is the validation
Eddy Nigg wrote:
On 02/19/2009 03:30 PM, Jean-Marc Desperrier:
Moxie Marlinspike in Black Hat has just demonstrated a very serious i18n
attack using a *.ijjk.cn certificate.
http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
.cn is
On 02/20/2009 05:55 PM, Jean-Marc Desperrier:
Get a domain-validated SSL wildcard cert for *.ijjk.cn
Yes, it's surprising how some of such attacks seem obvious *after* they
have been done, but it takes so long to realize it can be done.
Not exactly. I found it striking because we've been
Jean-Marc Desperrier wrote, On 2009-02-20 07:55:
Eddy Nigg wrote:
On 02/19/2009 03:30 PM, Jean-Marc Desperrier:
Moxie Marlinspike in Black Hat has just demonstrated a very serious i18n
attack using a *.ijjk.cn certificate.
On Feb 20, 7:55 am, Jean-Marc Desperrier jmd...@alussinan.org wrote:
Eddy Nigg wrote:
On 02/19/2009 03:30 PM, Jean-Marc Desperrier:
Moxie Marlinspike in Black Hat has just demonstrated a very serious i18n
attack using a *.ijjk.cn certificate.
If you'd like to try out something similar, you can go to
about:config and set browser.identity.ssl_domain_display to
1 (1st level domain only) or 2 (entire domain name).
Lucas.
On Feb 20, 2009, at 11:06 AM, evilredsca...@gmail.com wrote:
On Feb 20, 7:55 am, Jean-Marc Desperrier
30 matches
Mail list logo
