Nelson Bolyard wrote:
I meant to do for seamonkey what FF 1.0.1 did for FF 1.0 with respect
to IDN/punycode, whatever that was.
(I don't know what FF 1.0.1 did. Please elighten.)
OK. It did two things:
1) Make the network.enableIDN work properly
2) Implement a new pref, network.IDN_show_punycode,
Michael Roitzsch wrote:
If I understand things correctly, you want to have the browser maintain a sort
of whitelist of domains the user trusts. Whenever the browser encounters a
new SSL domain, the user is asked, if she wants to include it in the list of
trusted domains. Have I gotten the idea
Hi,
If I understand things correctly, you want to have the browser maintain a
sort of whitelist of domains the user trusts. Whenever the browser
encounters a new SSL domain, the user is asked, if she wants to include
it in the list of trusted domains. Have I gotten the idea right?
Nope.
Michael Roitzsch wrote:
Hi,
If I understand things correctly, you want to have the browser maintain a
sort of whitelist of domains the user trusts. Whenever the browser
encounters a new SSL domain, the user is asked, if she wants to include
it in the list of trusted domains. Have I gotten the
Hi,
All right, but what's this about then:
http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-b
im.jpg
Could you enlighten me?
This screenshot has nothing to do with the (final) implementation for
Mozilla Firefox and was discussed as a possible solution only. Note
Gervase Markham wrote:
Michael Roitzsch wrote:
If I understand things correctly, you want to have the browser
maintain a sort of whitelist of domains the user trusts. Whenever the
browser encounters a new SSL domain, the user is asked, if she wants
to include it in the list of trusted domains.
I saw this proposed on Bugtraq; I think the participants there explained
quite well why it wouldn't work. But thank you for your input :-)
reference?
See this thread:
http://www.securityfocus.com/archive/1/392472/2005-03-07/2005-03-13/1
Michael
--
A computer programmer is someone who,
Nelson Bolyard wrote:
I'll bet the error message you get contains more than just that number.
Does it contain much more than : couldn't establish a secure connection
to xxx error code -8075 ? (at least this message use the correct format
for the error, it's better than 'error e00b' when it
Michael Roitzsch wrote:
All right, but what's this about then:
http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bim.jpg
Could you enlighten me?
That's HJ's proposal - you'd need to ask him about that. But I don't
think it fits your definition. Maybe I'm wrong - after all,
Gervase Markham wrote:
Idea off the top of my head - please tell me why it won't work.
Could we parse all form submissions over unencrypted channels and put up
an alert (You _really_ don't want to do this!) if any of the fields
was a sixteen-digit number which passed the credit-card-number
Gervase Markham wrote:
Idea off the top of my head - please tell me why it won't work.
Could we parse all form submissions over unencrypted channels and put up
an alert (You _really_ don't want to do this!) if any of the fields
was a sixteen-digit number which passed the credit-card-number
Ian G wrote:
Gervase Markham wrote:
Idea off the top of my head - please tell me why it won't work.
Could we parse all form submissions over unencrypted channels and put
up an alert (You _really_ don't want to do this!) if any of the
fields was a sixteen-digit number which passed the
Hi,
What's proposed is a list of trusted (or untrusted) TLDs, set by us.
Again, this is new, and this was certainly not part of your first and
second proposals.
He is talking about solutions specific to the IDN homograph attacks.
I think the discussion has already moved to more general
13 matches
Mail list logo
