Unicode domain names issue (Encrypting a "fake" domain name)

classic Classic list List threaded Threaded
66 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Boris Zbarsky
On 4/20/17 6:54 PM, Eli the Bearded wrote:
> More baked: Using the confusables list from Unicode, if a domain label
> consists entirely of letters in one script that are "confusable" to
> another (single) script, start raising red flags.

So just to be clear, per that proposal we should be raising red flags on
the "real" epic.com and keep.com and so forth, right?

-Boris
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Gervase Markham
In reply to this post by Martin Heaps
On 20/04/17 23:54, Eli the Bearded wrote:
> More baked: Using the confusables list from Unicode, if a domain label
> consists entirely of letters in one script that are "confusable" to
> another (single) script, start raising red flags.

So we raise a red flag on http://apple.com, the site for the largest
tech company in the world?

Or did you mean "if a domain label consists entirely of letters in one
non-Latin script..."? If so, we've just got back to a situation of
privileging one script over another.

Gerv
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Gervase Markham
In reply to this post by Gervase Markham
On 21/04/17 02:36, Kyle Hamilton wrote:
> Perhaps, only display non-punycode from codepoint sets used in
> languages already installed on the computer?

Before we do another canter through the six different ideas that always
occur to people when first presented with this issue, the very unofficial
https://wiki.mozilla.org/Gerv%27s_IDN_Display_Algorithm_FAQ
might help shortcut the process. In this case, questions 7-9 are
relevant, as your proposal is a variant of the one those address.

Gerv

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Igor Bukanov-2
In reply to this post by Eli the Bearded
On 21 April 2017 at 00:54, Eli the Bearded <*@eli.users.panix.com> wrote:
> Objection. Configuration to not record history is trivial, and even
> if not configured such, some confusables could easily be sites that
> the user doesn't visit often enough to have in history.

Still the history is very valuable to dismiss it because it does not
work in all cases. At the very list in a typical case the history
shows what kind of scripts the user ever visited per top-level domain
allowing to flag unexpected script. For example, personally I will be
very suspicious about a Cyrillic.com domain as those are awkward to
type (one has to change the keyboard layout in the middle). If a site
needs Russian domain, I expect it to use .рф not .com

> More baked: Using the confusables list from Unicode, if a domain label
> consists entirely of letters in one script that are "confusable" to
> another (single) script, start raising red flags.

The problem is that at least for Russian/English language the words
consisting of only confusable characters are frequent enough to bring
way too many false positives to be usable.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Chaddaï Fouché
In reply to this post by Gervase Markham
Le vendredi 21 avril 2017 12:28:41 UTC+2, Gervase Markham a écrit :
>
> Before we do another canter through the six different ideas that always
> occur to people when first presented with this issue, the very unofficial
> https://wiki.mozilla.org/Gerv%27s_IDN_Display_Algorithm_FAQ
> might help shortcut the process.

The initial proposition of Igor Bukanov (that every domain name be preceded by an icon indicating the writing system, yes, even the latin ones) seems completely neutral regarding non-latin languages and not very obtrusive.

I'm pretty sure most non-technical people don't even look at the url bar and don't care about the icons that already appear there : info, lock, read mode, zooming state, reload. Adding just one more probably won't suddenly overload them and it would allow every technically minded people to see instantly if the domain name is in the writing system they expect. Your IDN algorithm already compute this information anyway.

Your reaction amounting to "we give priority to our ideal of handling every language equally over security (of everyone, regardless of their language) because we consider 1) that it's the fault of the registrars (irrelevant from the user point of view, and unlikely to be fixed from that side) and 2) that our users are fragile little flowers that will be scared by any additional UI element (that's insulting by the way even if a cleaner UI is a worthy goal)" is giving me second thoughts about staying with Firefox after almost 15 years with Mozilla (since the 1.0 version)... Ideals are one of the reason I stayed with the Mozilla foundation so I'm not faulting you on that but on your priorities : security for your users should really be more important than avoiding *anything* that could offense their sensibility.

--
Chaddaï Fouché
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Kyle Hamilton
In reply to this post by Gervase Markham
The idea may be a variant, but it's by no means the same as what has
been presented there.

In the instant case, the font used in the address bar uses the same
glyph shapes for both Latin and Cyrillic.  Might it be appropriate to
use (and provide) a font that uses different glyphs for every
confusable code point, and then provide some kind of user training on
how if the shapes don't match what they're used to it might be
phishing?  This would be demonstrably script-neutral.

The downside is that it would unduly burden users whose
shape-recognition is sub-par, but pretty much every other idea for
protecting the users has been shot down by Mozilla reps on this list.
I'm sorry, but this is not "somebody else's problem".  The users use
your software, and you are the only ones they can hope to save them
from threats that others refuse to take responsibility for.

Mozilla has always claimed that it's focused on user security.  If
you're enforcing the rule "if it works on one Firefox, it works on all
Firefoxes" (in the context of "IDN owners might not use IDN if IDN
doesn't work everywhere") to the detriment of user security and
increasing phishability, are you really focused on user security?  Why
is IDN display a sacred cow, when it increases the risk for your users
to be scammed?  IDN owners don't apparently provide mindshare to
Mozilla, nor contribute to the installed base.

Mozilla reps on this list have tried to push the problem off on
everyone else -- the registrars (of which a subset refuse to accept
the responsibility, and cannot be compelled to do so), and the users
who have no means to differentiate in the scripts (because IDN owners
can't abide uncertainty).  For some reason, though, you're not trying
to push the problem off onto the IDN owners who, as web site owners,
already have to deal with the uncertainty of their users using
whatever browsers with whatever security policies baked in that they
choose to.

-Kyle H


On Fri, Apr 21, 2017 at 3:28 AM, Gervase Markham <[hidden email]> wrote:

> On 21/04/17 02:36, Kyle Hamilton wrote:
>> Perhaps, only display non-punycode from codepoint sets used in
>> languages already installed on the computer?
>
> Before we do another canter through the six different ideas that always
> occur to people when first presented with this issue, the very unofficial
> https://wiki.mozilla.org/Gerv%27s_IDN_Display_Algorithm_FAQ
> might help shortcut the process. In this case, questions 7-9 are
> relevant, as your proposal is a variant of the one those address.
>
> Gerv
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Alex Gaynor-2
This thread is very focused on what's the right algorithm for preventing
homoglyph attacks. But why do we care about homoglyphs? Because they make
phishing for credentials easier.

But do homoglyphs need unique handling vs, other phishing attacks? First,
it's clear that homoglyphs are not a necessary component of a phishing
attack, facebook-com.nonsense.biz is also an effective strategy for
phishers. Homoglyphs are particularly scary to us though, because no amount
of training or vigilance on the part of users will work, we must have a
machine solution.

Given that, what machine solutions do we have for _all_ phishing attacks.

- There's ongoing work to implement U2F, to provide phishing-proof
credentials
- We use Google's SafeBrowsing API to check for known phishing sites.
- Probably there's lots of other things we already do that I don't even
realize!

But I agree with those who've argued for "the buck stops here" -- if
there's more we can do, we must, because even if registrars prevent
homoglyph there's 1001 other effective phishing techniques that need to be
stopped.

- Are there clever clientside algorithms we can use to detect phishing
websites above what SafeBrowsing gives us?
- Should the UI surface "this is your first time visiting this website"?

There's probably other good ideas out there.

Cheers,
Alex

On Fri, Apr 21, 2017 at 2:42 PM, Kyle Hamilton <[hidden email]> wrote:

> The idea may be a variant, but it's by no means the same as what has
> been presented there.
>
> In the instant case, the font used in the address bar uses the same
> glyph shapes for both Latin and Cyrillic.  Might it be appropriate to
> use (and provide) a font that uses different glyphs for every
> confusable code point, and then provide some kind of user training on
> how if the shapes don't match what they're used to it might be
> phishing?  This would be demonstrably script-neutral.
>
> The downside is that it would unduly burden users whose
> shape-recognition is sub-par, but pretty much every other idea for
> protecting the users has been shot down by Mozilla reps on this list.
> I'm sorry, but this is not "somebody else's problem".  The users use
> your software, and you are the only ones they can hope to save them
> from threats that others refuse to take responsibility for.
>
> Mozilla has always claimed that it's focused on user security.  If
> you're enforcing the rule "if it works on one Firefox, it works on all
> Firefoxes" (in the context of "IDN owners might not use IDN if IDN
> doesn't work everywhere") to the detriment of user security and
> increasing phishability, are you really focused on user security?  Why
> is IDN display a sacred cow, when it increases the risk for your users
> to be scammed?  IDN owners don't apparently provide mindshare to
> Mozilla, nor contribute to the installed base.
>
> Mozilla reps on this list have tried to push the problem off on
> everyone else -- the registrars (of which a subset refuse to accept
> the responsibility, and cannot be compelled to do so), and the users
> who have no means to differentiate in the scripts (because IDN owners
> can't abide uncertainty).  For some reason, though, you're not trying
> to push the problem off onto the IDN owners who, as web site owners,
> already have to deal with the uncertainty of their users using
> whatever browsers with whatever security policies baked in that they
> choose to.
>
> -Kyle H
>
>
> On Fri, Apr 21, 2017 at 3:28 AM, Gervase Markham <[hidden email]> wrote:
> > On 21/04/17 02:36, Kyle Hamilton wrote:
> >> Perhaps, only display non-punycode from codepoint sets used in
> >> languages already installed on the computer?
> >
> > Before we do another canter through the six different ideas that always
> > occur to people when first presented with this issue, the very unofficial
> > https://wiki.mozilla.org/Gerv%27s_IDN_Display_Algorithm_FAQ
> > might help shortcut the process. In this case, questions 7-9 are
> > relevant, as your proposal is a variant of the one those address.
> >
> > Gerv
> >
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Eli the Bearded
In reply to this post by Martin Heaps
In mozilla.dev.security, Boris Zbarsky  <[hidden email]> wrote:
> On 4/20/17 6:54 PM, Eli the Bearded wrote:
>> More baked: Using the confusables list from Unicode, if a domain label
>> consists entirely of letters in one script that are "confusable" to
>> another (single) script, start raising red flags.
> So just to be clear, per that proposal we should be raising red flags on
> the "real" epic.com and keep.com and so forth, right?

The (alas unwritten) bit that is important in my proposal is that this
confusable check only happens for punycode DNS labels.

This example I posted elsewhere might be helpful to demonstate my idea:

    This site, https://www.xn--80ak6aa92e.com/, uses the Cyrillic
    alphabet to create a URL that resembles the Latin alphabet
    "www.apple.com". Do you wish to continue?

Elijah
------
might not be good enough for "full baked" yet
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Eli the Bearded
In reply to this post by Eli the Bearded
In mozilla.dev.security, Igor Bukanov  <[hidden email]> wrote:
> On 21 April 2017 at 00:54, Eli the Bearded <*@eli.users.panix.com> wrote:
>> More baked: Using the confusables list from Unicode, if a domain label
>> consists entirely of letters in one script that are "confusable" to
>> another (single) script, start raising red flags.
> The problem is that at least for Russian/English language the words
> consisting of only confusable characters are frequent enough to bring
> way too many false positives to be usable.

Hmmm. Checking for Cyrillic to Latin / Digit issues in confusables.txt,
there are more than I had suspected.


A644 ;  0032 ;  MA      # ( Ꙅ → 2 ) CYRILLIC CAPITAL LETTER REVERSED DZE → DIGIT TWO    # →Ƨ→
0417 ;  0033 ;  MA      # ( З → 3 ) CYRILLIC CAPITAL LETTER ZE → DIGIT THREE    #
04E0 ;  0033 ;  MA      # ( Ӡ → 3 ) CYRILLIC CAPITAL LETTER ABKHASIAN DZE → DIGIT THREE # →Ʒ→
0431 ;  0036 ;  MA      # ( б → 6 ) CYRILLIC SMALL LETTER BE → DIGIT SIX        #

0430 ;  0061 ;  MA      # ( а → a ) CYRILLIC SMALL LETTER A → LATIN SMALL LETTER A      #
0410 ;  0041 ;  MA      # ( А → A ) CYRILLIC CAPITAL LETTER A → LATIN CAPITAL LETTER A  #
042C ;  0062 ;  MA      # ( Ь → b ) CYRILLIC CAPITAL LETTER SOFT SIGN → LATIN SMALL LETTER B    # →Ƅ→
0412 ;  0042 ;  MA      # ( В → B ) CYRILLIC CAPITAL LETTER VE → LATIN CAPITAL LETTER B #
0441 ;  0063 ;  MA      # ( с → c ) CYRILLIC SMALL LETTER ES → LATIN SMALL LETTER C     #
0421 ;  0043 ;  MA      # ( С → C ) CYRILLIC CAPITAL LETTER ES → LATIN CAPITAL LETTER C #
0501 ;  0064 ;  MA      # ( ԁ → d ) CYRILLIC SMALL LETTER KOMI DE → LATIN SMALL LETTER D        #
0435 ;  0065 ;  MA      # ( е → e ) CYRILLIC SMALL LETTER IE → LATIN SMALL LETTER E     #
0415 ;  0045 ;  MA      # ( Е → E ) CYRILLIC CAPITAL LETTER IE → LATIN CAPITAL LETTER E #
050C ;  0047 ;  MA      # ( Ԍ → G ) CYRILLIC CAPITAL LETTER KOMI SJE → LATIN CAPITAL LETTER G   #
04BB ;  0068 ;  MA      # ( һ → h ) CYRILLIC SMALL LETTER SHHA → LATIN SMALL LETTER H   #
041D ;  0048 ;  MA      # ( Н → H ) CYRILLIC CAPITAL LETTER EN → LATIN CAPITAL LETTER H #
0456 ;  0069 ;  MA      # ( і → i ) CYRILLIC SMALL LETTER BYELORUSSIAN-UKRAINIAN I → LATIN SMALL LETTER I       #
0458 ;  006A ;  MA      # ( ј → j ) CYRILLIC SMALL LETTER JE → LATIN SMALL LETTER J     #
0408 ;  004A ;  MA      # ( Ј → J ) CYRILLIC CAPITAL LETTER JE → LATIN CAPITAL LETTER J #
043A ;  006B ;  MA      # ( к → k ) CYRILLIC SMALL LETTER KA → LATIN SMALL LETTER K     #
041A ;  004B ;  MA      # ( К → K ) CYRILLIC CAPITAL LETTER KA → LATIN CAPITAL LETTER K #
0406 ;  006C ;  MA      # ( І → l ) CYRILLIC CAPITAL LETTER BYELORUSSIAN-UKRAINIAN I → LATIN SMALL LETTER L     #
041C ;  004D ;  MA      # ( М → M ) CYRILLIC CAPITAL LETTER EM → LATIN CAPITAL LETTER M #
043F ;  006E ;  MA      # ( п → n ) CYRILLIC SMALL LETTER PE → LATIN SMALL LETTER N     #
043E ;  006F ;  MA      # ( о → o ) CYRILLIC SMALL LETTER O → LATIN SMALL LETTER O      #
041E ;  004F ;  MA      # ( О → O ) CYRILLIC CAPITAL LETTER O → LATIN CAPITAL LETTER O  #
0440 ;  0070 ;  MA      # ( р → p ) CYRILLIC SMALL LETTER ER → LATIN SMALL LETTER P     #
0420 ;  0050 ;  MA      # ( Р → P ) CYRILLIC CAPITAL LETTER ER → LATIN CAPITAL LETTER P #
051B ;  0071 ;  MA      # ( ԛ → q ) CYRILLIC SMALL LETTER QA → LATIN SMALL LETTER Q     #
0433 ;  0072 ;  MA      # ( г → r ) CYRILLIC SMALL LETTER GHE → LATIN SMALL LETTER R    #
0455 ;  0073 ;  MA      # ( ѕ → s ) CYRILLIC SMALL LETTER DZE → LATIN SMALL LETTER S    #
0405 ;  0053 ;  MA      # ( Ѕ → S ) CYRILLIC CAPITAL LETTER DZE → LATIN CAPITAL LETTER S        #
0442 ;  0074 ;  MA      # ( т → t ) CYRILLIC SMALL LETTER TE → LATIN SMALL LETTER T     # →τ→
0422 ;  0054 ;  MA      # ( Т → T ) CYRILLIC CAPITAL LETTER TE → LATIN CAPITAL LETTER T #
0446 ;  0075 ;  MA      # ( ц → u ) CYRILLIC SMALL LETTER TSE → LATIN SMALL LETTER U    #
0475 ;  0076 ;  MA      # ( ѵ → v ) CYRILLIC SMALL LETTER IZHITSA → LATIN SMALL LETTER V        #
0474 ;  0056 ;  MA      # ( Ѵ → V ) CYRILLIC CAPITAL LETTER IZHITSA → LATIN CAPITAL LETTER V    #
051C ;  0057 ;  MA      # ( Ԝ → W ) CYRILLIC CAPITAL LETTER WE → LATIN CAPITAL LETTER W #
0445 ;  0078 ;  MA      # ( х → x ) CYRILLIC SMALL LETTER HA → LATIN SMALL LETTER X     #
0425 ;  0058 ;  MA      # ( Х → X ) CYRILLIC CAPITAL LETTER HA → LATIN CAPITAL LETTER X #
0443 ;  0079 ;  MA      # ( у → y ) CYRILLIC SMALL LETTER U → LATIN SMALL LETTER Y      #
04AF ;  0079 ;  MA      # ( ү → y ) CYRILLIC SMALL LETTER STRAIGHT U → LATIN SMALL LETTER Y     # →γ→
04AE ;  0059 ;  MA      # ( Ү → Y ) CYRILLIC CAPITAL LETTER STRAIGHT U → LATIN CAPITAL LETTER Y #

I don't have a Russian wordlist to compare to any of the English
wordlists I do have (and that would be subpar because my English word
lists don't include internet names like "paypal" (CYRILLIC: ER A U ER A
BYELORUSSIAN-UKRAINIAN I)). But, yeah, I can see potential for there
being a lot of natural overlaps.

Elijah
------
possibly some in ARMENIAN and other widely used alphabets, too

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Boris Zbarsky
In reply to this post by Martin Heaps
On 4/21/17 3:07 PM, Eli the Bearded wrote:
> The (alas unwritten) bit that is important in my proposal is that this
> confusable check only happens for punycode DNS labels.

Right, which comes back to the "yeah, English is the only language
anyone should be speaking, and screw people who might be using other
languages" problem.  I know that's not the intention, but that's the effect.

-Boris
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Gervase Markham
In reply to this post by Gervase Markham
On 21/04/17 18:25, Chaddaï Fouché wrote:
> I'm pretty sure most non-technical people don't even look at the url
> bar and don't care about the icons that already appear there : info,
> lock, read mode, zooming state, reload.

So why do you think adding another icon will solve this problem?

> Adding just one more probably
> won't suddenly overload them and it would allow every technically
> minded people to see instantly if the domain name is in the writing
> system they expect. Your IDN algorithm already compute this
> information anyway.

So we are trying to solve the problem only for technically minded people?

> Your reaction amounting to "we give priority to our ideal of handling
> every language equally over security (of everyone, regardless of
> their language) because we consider 1) that it's the fault of the
> registrars (irrelevant from the user point of view, and unlikely to
> be fixed from that side) and 2) that our users are fragile little
> flowers that will be scared by any additional UI element (that's
> insulting by the way even if a cleaner UI is a worthy goal)"

Well, that's basically what you just said above :-)

Gerv
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Gervase Markham
In reply to this post by Gervase Markham
On 21/04/17 19:42, Kyle Hamilton wrote:
> In the instant case, the font used in the address bar uses the same
> glyph shapes for both Latin and Cyrillic.  Might it be appropriate to
> use (and provide) a font that uses different glyphs for every
> confusable code point, and then provide some kind of user training on
> how if the shapes don't match what they're used to it might be
> phishing?  This would be demonstrably script-neutral.

Whose letters get distorted and whose letters get to stay the same?

If the differences are only small, the chances are people won't notice.
If they don't notice apple.com.example.com, then they won't notice this.

> The downside is that it would unduly burden users whose
> shape-recognition is sub-par, but pretty much every other idea for
> protecting the users has been shot down by Mozilla reps on this list.
> I'm sorry, but this is not "somebody else's problem".  The users use
> your software, and you are the only ones they can hope to save them
> from threats that others refuse to take responsibility for.

Is it a bird? Is it a plane? No... it's a dinosaur!

> Mozilla has always claimed that it's focused on user security.  If
> you're enforcing the rule "if it works on one Firefox, it works on all
> Firefoxes" (in the context of "IDN owners might not use IDN if IDN
> doesn't work everywhere") to the detriment of user security and
> increasing phishability, are you really focused on user security?  Why
> is IDN display a sacred cow, when it increases the risk for your users
> to be scammed?  IDN owners don't apparently provide mindshare to
> Mozilla, nor contribute to the installed base.

Are you properly assessing the level of the risk? Unlike mixed-script
systems, there is at most 1 and normally 0 Cyrillic whole-script
homographs of any domain. That means that now we've done this dance,
no-one can ever do this to Apple again. I would expect other major
domain owners who are paying attention to be going out there and
spending all of $7 on the Cyrillic homograph of their domain, if there
is one.

> Mozilla reps on this list have tried to push the problem off on
> everyone else -- the registrars (of which a subset refuse to accept
> the responsibility, and cannot be compelled to do so),

So it's OK for them to say it's not their responsibility but not OK for
us to say it's not our responsibility?

Or is what you mean that because we have an open process, there's more
chance of shouting at us until we do something than there is of shouting
a the registries until they do something?

Gerv
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Gervase Markham
In reply to this post by Kyle Hamilton
On 21/04/17 19:59, Alex Gaynor wrote:
> But I agree with those who've argued for "the buck stops here" -- if
> there's more we can do, we must

Can I just note in passing that, independent of what we do here, "if
there's more we can do, we must" is a terrible, terrible argument?

Everything's a trade-off. Time, money, complexity, risk. Taking one
particular problem and saying "this risk must be eliminated to the
uttermost, regardless of how much time, money and added complexity is
needed" is just not a reasonable position.

Gerv
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

L. David Baron
In reply to this post by Igor Bukanov-2
On Friday 2017-04-21 13:05 +0200, Igor Bukanov wrote:

> On 21 April 2017 at 00:54, Eli the Bearded <*@eli.users.panix.com> wrote:
> > Objection. Configuration to not record history is trivial, and even
> > if not configured such, some confusables could easily be sites that
> > the user doesn't visit often enough to have in history.
>
> Still the history is very valuable to dismiss it because it does not
> work in all cases. At the very list in a typical case the history
> shows what kind of scripts the user ever visited per top-level domain
> allowing to flag unexpected script. For example, personally I will be
> very suspicious about a Cyrillic.com domain as those are awkward to
> type (one has to change the keyboard layout in the middle). If a site
> needs Russian domain, I expect it to use .рф not .com
This makes me wonder:  could we become more suspicious (in terms of
UI indications) of sites where the script changes between different
parts of the hostname (or eTLD+1), i.e., move towards expecting that
non-Latin domain names will be using a non-Latin TLD?

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Robert Kaiser
In reply to this post by Kyle Hamilton
Gervase Markham schrieb:
> Everything's a trade-off. Time, money, complexity, risk. Taking one
> particular problem and saying "this risk must be eliminated to the
> uttermost, regardless of how much time, money and added complexity is
> needed" is just not a reasonable position.

While that's true, right now, our position has the risk of the
completely wrong point that Mozilla doesn't care if phishing happens to
our users or by extension about their security. Now, we all know that
this is both extremely far from the truth  - but esp. if other browsers
"do something" (no matter how useful that "something" is) and we "do
nothing" and "play the blame game" by saying it's someone else's fault
(Douglas Adams fans would call it a "SEP field") then it's easy for
outsiders to get that wrong improession.

It's also a truism that being right is not always enough to make the
right things. I think we need to do some kind of "mitigation" in the
light of not looking worse than our competitors (which we do often
enough unfortunately).

I think, in hindsight, it was a bad idea to abandon the whitelisting
approach - even though it looked perfectly fine back then. We probably
would have needed to a model somewhat similar to how we run the root CA
list: After seeing the whitelists with what we had from our own research
before, only add new TLDs that request that from their side and prove
that they follow certain rules (esp. anti-homograph-attack ones). Move
as much of the burden to those that actually make money selling IDN
domains. The maintenenace of the list and setting of rules could
potentially have been even in some common form between all or some of
Mozilla, Google, Microsoft, and Apple. The alternative would have been
to not allow IDN for new TLDs at all unless ICANN enforces rules of that
kind (given that ICANN makes money with granting TLDs, that also would
fit the "put the burden where the financial incentive is) - and that
could potentially have been in accordance with other browser vendors as
well.

Maybe we can now have some influence on ICANN so they actually set up
anti-homograph-attack rules for TLDs, are we in talks with them on that?

That said, if any activities on the side of registires cannot be reached
fast, I fear we need to ship "somthing" in Firefox that doesn't
"something" to help or we risk being stamped "insecure" or
"phisihing-friendly" even if that's not true.

KaiRo
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Chaddaï Fouché
In reply to this post by Gervase Markham
Le lun. 24 avr. 2017 à 11:00, Gervase Markham <[hidden email]> a écrit :

> On 21/04/17 18:25, Chaddaï Fouché wrote:
> > I'm pretty sure most non-technical people don't even look at the url
> > bar and don't care about the icons that already appear there : info,
> > lock, read mode, zooming state, reload.
>
> So why do you think adding another icon will solve this problem?
>
>
Clearly _as I wrote in this quote_, I don't think it will help for
*non-technical people*, but then neither would deactivating IDN support
help either since most people only see the content of the site and if it
looks like an apple site, it must be from apple, right ? A minority has now
trained themselves to look at the lock but that won't help much here. The
only protection that would work is SafeBrowsing which is very good when it
works but obviously can't protect against every phishing website
instantaneously after its creation (and they don't want to make a blanket
block against this potential problem, from what I understand ?).


> > Adding just one more probably
> > won't suddenly overload them and it would allow every technically
> > minded people to see instantly if the domain name is in the writing
> > system they expect. Your IDN algorithm already compute this
> > information anyway.
>
> So we are trying to solve the problem only for technically minded people?
>
>
And ? How is a solution that won't inconvenience non-technical people but
help technically minded people bad ? Or are you implying that technically
minded people shouldn't be considered in Mozilla's decision ? Because in
case you've forgotten, an important minority of your public is technically
minded, and most of those who aren't installed Firefox because they were
advised so by their technically minded friend... unless you think your
enormous PR prowess and your unlimited ad budget were the main reason for
your success ?
The proposed solution is not miraculous but it solves the problem that even
technically minded people can't see that the site is fake even by looking
at the url bar, even by looking at the information from the certificate
that appears when clicking on the lock... Sure you can copy and paste the
url to an ascii editor but nobody will do that for every website, even
sensible websites. Convenience is important for technically minded people
too, even if they have a higher threshold for convenience vs security.


> > Your reaction amounting to "we give priority to our ideal of handling
> > every language equally over security (of everyone, regardless of
> > their language) because we consider 1) that it's the fault of the
> > registrars (irrelevant from the user point of view, and unlikely to
> > be fixed from that side) and 2) that our users are fragile little
> > flowers that will be scared by any additional UI element (that's
> > insulting by the way even if a cleaner UI is a worthy goal)"
>
> Well, that's basically what you just said above :-)
>
>
So the solution that propose to add an icon in the url bar to improve
security is somehow synonymous to :
1) give priority to every other ideals over security
2) it's the fault of the registrars
3) our users are fragile little flowers that will be scared by any
additional UI element
??
Words must not have the same meaning for you and I...


> Everything's a trade-off. Time, money, complexity, risk. Taking one
> particular problem and saying "this risk must be eliminated to the
> uttermost, regardless of how much time, money and added complexity is
> needed" is just not a reasonable position.

Sure, but some of the proposed solutions aren't huge time sinks, mine
(Igor's) for instance only means adding an UI element in the URL bar,
something that has already been done and can probably be reproduced without
too much innovation. What would take the most time would probably be to
find reasonable abbreviations for the writing systems and testing
afterward. The time spent discussing this issue would have been enough to
implement this several times over.

--
Chaddaï Fouché
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Alex Gaynor-2
In reply to this post by Gervase Markham
You're right Gerv, everything is a trade-off. If I could resend that email,
I'd stress that "we" is the most important part of that sentence, not "if
there's more, it must be done". Specifically, my position is that just
because the registrars, or someone else, _should_ have done something,
doesn't make a good reason for us _not_ to do something.

We are the user's agent, and we should balance priorities in serving our
users against each other, not against what someone else could have done :-)

As I said, I think the right solution is to invest in more general phishing
mitigation, but if one believes that homoglyphs are particularly
threatening, I don't think it's relevant that registers could have done
something.

Alex

On Mon, Apr 24, 2017 at 5:06 AM, Gervase Markham <[hidden email]> wrote:

> On 21/04/17 19:59, Alex Gaynor wrote:
> > But I agree with those who've argued for "the buck stops here" -- if
> > there's more we can do, we must
>
> Can I just note in passing that, independent of what we do here, "if
> there's more we can do, we must" is a terrible, terrible argument?
>
> Everything's a trade-off. Time, money, complexity, risk. Taking one
> particular problem and saying "this risk must be eliminated to the
> uttermost, regardless of how much time, money and added complexity is
> needed" is just not a reasonable position.
>
> Gerv
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Frederik Braun
In reply to this post by Robert Kaiser
On 24.04.2017 13:40, Robert Kaiser wrote:

> Gervase Markham schrieb:
>> Everything's a trade-off. Time, money, complexity, risk. Taking one
>> particular problem and saying "this risk must be eliminated to the
>> uttermost, regardless of how much time, money and added complexity is
>> needed" is just not a reasonable position.
>
> While that's true, right now, our position has the risk of the
> completely wrong point that Mozilla doesn't care if phishing happens to
> our users or by extension about their security. Now, we all know that
> this is both extremely far from the truth  - but esp. if other browsers
> "do something" (no matter how useful that "something" is) and we "do
> nothing" and "play the blame game" by saying it's someone else's fault
> (Douglas Adams fans would call it a "SEP field") then it's easy for
> outsiders to get that wrong improession.

FWIW, if this web page was actively phishing users, we would block it
through Safe Browsing. This one is not.

So the problem here is about deducing (from the domain name) if a
website is phishy. That's admittedly hard.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Kyle Hamilton
In reply to this post by Gervase Markham
On Mon, Apr 24, 2017 at 2:04 AM, Gervase Markham <[hidden email]> wrote:
> On 21/04/17 19:42, Kyle Hamilton wrote:
>> In the instant case, the font used in the address bar uses the same
>> glyph shapes for both Latin and Cyrillic.  Might it be appropriate to
>> use (and provide) a font that uses different glyphs for every
>> confusable code point, and then provide some kind of user training on
>> how if the shapes don't match what they're used to it might be
>> phishing?  This would be demonstrably script-neutral.
>
> Whose letters get distorted and whose letters get to stay the same?

Anything that is not U+0020 to U+007F gets altered.

> If the differences are only small, the chances are people won't notice.
> If they don't notice apple.com.example.com, then they won't notice this.

Then it's probably a user training issue: how many people even look at
the address bar after they click a link?  Create a UI that trains them
to look at it.

Or, you know, a UI that pops up a "if this is supposed to be Apple
Computer, it should look like 'apple.com'.  If the letters don't look
the same as this, you are not at Apple Computer's site." or something.

>> The downside is that it would unduly burden users whose
>> shape-recognition is sub-par, but pretty much every other idea for
>> protecting the users has been shot down by Mozilla reps on this list.
>> I'm sorry, but this is not "somebody else's problem".  The users use
>> your software, and you are the only ones they can hope to save them
>> from threats that others refuse to take responsibility for.
>
> Is it a bird? Is it a plane? No... it's a dinosaur!
>
>> Mozilla has always claimed that it's focused on user security.  If
>> you're enforcing the rule "if it works on one Firefox, it works on all
>> Firefoxes" (in the context of "IDN owners might not use IDN if IDN
>> doesn't work everywhere") to the detriment of user security and
>> increasing phishability, are you really focused on user security?  Why
>> is IDN display a sacred cow, when it increases the risk for your users
>> to be scammed?  IDN owners don't apparently provide mindshare to
>> Mozilla, nor contribute to the installed base.
>
> Are you properly assessing the level of the risk? Unlike mixed-script
> systems, there is at most 1 and normally 0 Cyrillic whole-script
> homographs of any domain. That means that now we've done this dance,
> no-one can ever do this to Apple again. I would expect other major
> domain owners who are paying attention to be going out there and
> spending all of $7 on the Cyrillic homograph of their domain, if there
> is one.

...I'm sure that Apple and Epic and whoever else are going to be quite
happy going through the UDHR process to seize ownership of their
homograph domains from whoever do currently own them.  You realize
that costs a bit more than $7, right?

>> Mozilla reps on this list have tried to push the problem off on
>> everyone else -- the registrars (of which a subset refuse to accept
>> the responsibility, and cannot be compelled to do so),
>
> So it's OK for them to say it's not their responsibility but not OK for
> us to say it's not our responsibility?

Correct.  They don't have contracts in place (EULAs) with individual
users, whereas you do.  They don't advertise that they operate for the
benefit or safety of the people who look up using their software or
services, whereas you do.  You're the ones whose software is actually
used by the users, with one-on-one relationships with you.  You're the
last and only line of defense for your users against the uncaring
policies of the rest of the Internet world.  (More importantly, Chrome
and Safari have accepted responsibility for their users' security on
this topic, and Mozilla is now the outlier.)

> Or is what you mean that because we have an open process, there's more
> chance of shouting at us until we do something than there is of shouting
> a the registries until they do something?

Wow.  Someone's taking this personally.

No, I mean that Mozilla has always in the past acted toward its users'
security, has always acted against homograph and easily-confusable
domains, and has always advertised that record.  This lack of action
is a marked departure from what it has done, and a marked departure
from its advertising.  It's not far-fetched to worry that there could
be legal liability here for false advertising.

Mozilla does have the ability to act for the benefit of its users
here.  But it seems that it no longer feels interested in doing so.

-Kyle H
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Gervase Markham
In reply to this post by Kyle Hamilton
On 24/04/17 12:40, Robert Kaiser wrote:
> I think, in hindsight, it was a bad idea to abandon the whitelisting
> approach

I don't agree. If ubiquity of IDNs is a goal, every IDN-using client
having its own whitelist would kill that goal stone dead.

> That said, if any activities on the side of registires cannot be reached
> fast, I fear we need to ship "somthing" in Firefox that doesn't
> "something" to help or we risk being stamped "insecure" or
> "phisihing-friendly" even if that's not true.

So you are suggesting we prioritize product changes based on
ill-informed media pressure?

Gerv

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
1234
Loading...