: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Saturday, February 09, 2002 18:28
Subject: Re: Unicode and Security
[EMAIL PROTECTED] scripsit:
Let's keep going. Latin Y, Greek Upsilon, Cyrillic U. Wait a
minute, that
Cyrillic U doesn't look *quite* the same
Elliotte Rusty Harold scripsit:
Another possibility is a super-normalization that does combine
similar looking Unicode characters; e.g. in the domain name system we
might decide that microsoft.com with Latin o's or Cyrillic o's or
Greek o's is to resolve to the same address.
In that
]
Subject: Re: Unicode and Security
In a message dated 2002-02-10 13:00:19 Pacific Standard Time,
[EMAIL PROTECTED] writes:
However, I do continue to maintain that character confusion is a real
security risk that will have real impact on users, and that needs to
be considered in any system
way
supports the there are security problems in Unicode thesis.
There are many characters which look alike, and yet are different,
which can cause problems of this kind. There are for example already
viruses which exploit the visual similarity between 1 and l in the
Windows system font to keep
In a message dated 2002-02-09 13:00:59 Pacific Standard Time,
[EMAIL PROTECTED] writes:
It seems to me that this problem really needs some other fix than the
merging of all similar-looking characters in all character sets. I
just can't see that working.
Even the merging part wouldn't work.
[EMAIL PROTECTED] scripsit:
Let's keep going. Latin Y, Greek Upsilon, Cyrillic U. Wait a minute, that
Cyrillic U doesn't look *quite* the same. Oh well, it's close enough, right?
And then there's the Cyrillic U with the straight descender, whic
actually does look just like its Latin and
Elliotte Rusty Harold wrote:
The problem is that all of these or any other client-based solution you
come up with is only going to be implemented in some clients. Many, and
at least initially most, users are not going to have any such
protections. This needs to be cut off at the protocol
At 17:42 -0500 2002-02-07, John Cowan wrote:
The only widely-deployed alternative approach I know of is
ETSI GSM 03.38 (used in mobile telephony),
A truly bizarre character set: it supports English, French,
mainland Scandinavian languages, Italian, Spanish with Graves, and
GREEK SHOUTING.
On
At 15:53 -0500 2002-02-07, Elliotte Rusty Harold wrote:
For text files, probably not. But for the domain name system the
world very well might. Indeed, maybe it should unless this problem
can be dealt with. I suspect it can be dealt with by prohibiting
script mixing in domain names (e.g. each
-Original Message-
From: Tom Gewecke [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 07, 2002 6:20 PM
To: [EMAIL PROTECTED]
Subject: Re: Unicode and Security: Domain Names
I note that companies like Verisign already claim to offer
domain names
in dozens of languages
In a message dated 2002-02-08 8:23:22 Pacific Standard Time,
[EMAIL PROTECTED] writes:
Does anyone know anything about RACE encoding and its properties?
I wrote an article on IDNS in December of 2000 which discusses the
approaches which were being debated at that time, including RACE. RACE
Hi Elliotte and others,
ERH Does anybody really need mixed Latin and Greek domain names?
This is the wrong approach altogether. If we want to be universal, we
can't exclude cases on a heuristic basis of no one is probably going
to need this.
BTW People will certainly want mixed Han and Latin
Hello Asmus and others,
I'm not sure Unicode can be fixed at this point. The flaws may be
too deeply embedded. The real solution may involve waiting until
companies and people start losing significant amounts of money as a
result of the flaws in Unicode, and then throwing it away and
replacing
At 15:53 -0500 2002-02-07, Elliotte Rusty Harold wrote:
For text files, probably not. But for the domain name system the world
very well might. Indeed, maybe it should unless this problem can be dealt
with. I suspect it can be dealt with by prohibiting script mixing in
domain names (e.g. each
At 06:18 PM 2/8/02 +0100, Philipp Reichmuth wrote:
Oh, it is very well possible to design a character set that supports
all of Latin, Cyrillic and Greek without being susceptible to this
problem beyond the familiar 1-l-|, 0-O dimension. The main premise is
to encode glyphs instead of characters
Moreover, the IDN WG documents are in final call, so if you have comments to
make on them, now is the time. Visit http://www.i-d-n.net/ and sub-scribe
(with a hyphen here so that listar does not interpret my post as a command!)
to their mailing list (and read their archives) before doing so.
The
I want to review these documents, but since time is short, maybe someone
can answer my question...
Are the actual domain names as stored in the DB going to be canonical
normalized Unicode strings? It seems this would go a long way towards
preventing spoofing ... no one would be allowed to
Moreover, the IDN WG documents are in final call, so if you have comments to
make on them, now is the time. Visit http://www.i-d-n.net/ and subscribe to
their mailing list (and read their archives) before doing so.
The documents in last call are:
1. Internationalizing Domain Names in
Are the actual domain names as stored in the DB going to be canonical
normalized Unicode strings? It seems this would go a long way towards
preventing spoofing ...
Names will be stored according to a normalization called Nameprep. Read the
Stringprep (general framework) and Nameprep (IDN
The recent discussions of this list about Internet domain name
spoofing through substitution of Unicode characters that have similar,
or identical, glyphs is an issue that has recently appeared in print
in a prominent journal:
@String{j-CACM = Communications of the ACM}
://www.macchiato.com
- Original Message -
From: Philipp Reichmuth [EMAIL PROTECTED]
To: Asmus Freytag [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, February 08, 2002 09:18
Subject: Re[2]: Unicode and Security
Hello Asmus and others,
I'm not sure Unicode can be fixed
Otto Stolz wrote:
Gaspar Sinai wrote:
Just because some companies who have influence on Unicode
Consortium use some algorithm, like backing store and re-mapping,
it does not mean that this is the only way. [...]
Yudit does convert the input to view order and back.
Now, this reveals
I (Marco Cimarosti) wrote:
Even the John Cowan's example becomes perfectly unambiguous,
if the bidi embedding levels are retained:
Case 1:
From visual order: the Arabs = BARA-LA
And bidi levels:222
Get logical order: the Arabs = AL-ARAB
Gaspar Sinai wrote:
I am thinking about electronically signed Unicode text documents
that are rendered correctly or believeed to be rendered correctly,
still they look different, seem to contain additional or do not
seem to contain some text when viewed with different viewers due
to some
John Hudson wrote:
I can make an OpenType font for that uses contextual substitution to
replace the phrase 'The licensee also agrees to pay the type designer
$10,000 every time he uses the lowercase e' with a series of invisible
non-spacing glyphs. Of course, the backing store will contain
At 11:54 AM -0700 2/6/02, John H. Jenkins wrote:
Right, but right now is that people are typing things like www.whitehouse.
com instead of www.whitehouse.gov (or, for that matter,
www.unicode.com). How likely is it that someone will accidentally
type www.s?mple.com instead of www.sample.com?
* Elliotte Rusty Harold
|
| Security and spoofing are very real issues that were never, as far
| as I know, even considered in the design of Unicode. It's unclear
| whether or not the problem can be fixed now. The Unicode community
| has been in serious denial about this for some time. That
I've been thinking about security issues in Unicode, and I've come up
with one that's quite scary and worse than any I've heard before. It
uses only plaintext, no fonts involved, doesn't require buggy
software, and works over e-mail instead of the Web. All it requires
added to the existing
On Thu, Feb 07, 2002 at 10:34:20AM -0500, Elliotte Rusty Harold wrote:
Security and spoofing are very real issues that were never, as far as
I know, even considered in the design of Unicode.
Unicode is a character encoding, not a glyph encoding. Furthermore, it's
a superset of a number of
At 12:22 -0500 2002-02-07, Elliotte Rusty Harold wrote:
For the sake of argument, let's call the company they work at
Microsoft, but this attack could hit most companies with a .com
address. Let's say I register microsoft.com, only the fifth letter
isn't a lower-case Latin o. It's actually a
At 11:53 AM 2/7/02 -0600, David Starner wrote:
a superset of a number of preexisting character sets, so that it was
possible for those users to move to Unicode without problems. Since
important preexisting character sets seperated Greek, Cyrillic and Latin
scripts, Unicode had to. Had Unicode not
At 12:22 PM 2/7/2002 -0500, Elliotte Rusty Harold wrote:
I've been thinking about security issues in Unicode, and I've come up with
one that's quite scary and worse than any I've heard before. It uses only
plaintext, no fonts involved, doesn't require buggy software, and works
over e-mail
On Thu, Feb 07, 2002 at 12:22:18PM -0500, Elliotte Rusty Harold wrote:
Interestingly, my attack works with a single character representation
(Unicode). It is not dependent on multiple charsets.
It also works with EUC-JP (and other Japanese charsets), all 8-bit
Russian representations, all
On Thu, Feb 07, 2002 at 10:34:20AM -0500, Elliotte Rusty Harold wrote:
Unicode is a character encoding, not a glyph encoding. Furthermore, it's
a superset of a number of preexisting character sets, so that it was
possible for those users to move to Unicode without problems. Since
important
I'm not sure Unicode can be fixed at this point. The flaws may be too
deeply embedded. The real solution may involve waiting until
companies and people start losing significant amounts of money as a
result of the flaws in Unicode, and then throwing it away and
replacing it with something
At 10:16 AM -0800 2/7/02, Barry Caplan wrote:
This is precisely the problem digital signing is meant to solve.
Signing means that Alice has encrypted the message with her private
key before sending to Bob. Bob then unencrypts the message using
Alice's public key. If the message does not
At 11:34 AM -0800 2/7/02, Asmus Freytag wrote:
But, as the discussion shows, spoofing on the word level (.com
for .gov) is alive and well, and supported by any character set
whatsoever. For that reason, it seems to promise little gain to
try to chase the holy grail of a multilingual character
On Thu, Feb 07, 2002 at 01:21:29PM -0500, Elliotte Rusty Harold wrote:
I'm not sure Unicode can be fixed at this point. The flaws may be too
deeply embedded. The real solution may involve waiting until
companies and people start losing significant amounts of money as a
result of the flaws
At 12:28 PM -0800 2/7/02, John Hudson wrote:
1. The software industry has already devised mechanisms to protect
against e-mail forgery, e.g. private-public key encryption.
And nobody uses them because they're too complex.
2. What you describe is criminal fraud and there are laws to protect
Elliotte Rusty Harold wrote:
Interesting tidbit: app1e.com (not APPLE.COM but APP1E.COM) is in
fact already registered. This attack may not be as theoretical as I
initially thought.
And a0l.com. (It even has a website: www.a0l.com.) [Which, incidentally,
induces a security hazard, by
Thursday, February 7, 2002
Would making the about to be misled respondent type the address of the
intended person (with a roman 'o', not a greek omicron) and then having
the system see if they match detect and thwart such tricks? The
respondent is
At 11:42 2/7/2002, Elliotte Rusty Harold wrote:
Burglary at the broken window level is alive and well. Therefore there's
little point to putting locks on doors.
I hope the fallacy of the above is obvious, but when translated into the
computer security domain it's all too common a
I think this is probably beginning to get off-topic, but
At 12:45 2/7/2002, Elliotte Rusty Harold wrote:
1. The software industry has already devised mechanisms to protect
against e-mail forgery, e.g. private-public key encryption.
And nobody uses them because they're too complex.
I think
At 10:21 2/7/2002, Elliotte Rusty Harold wrote:
I'm not sure Unicode can be fixed at this point. The flaws may be too
deeply embedded.
What flaws? The fact that glyphs in different scripts may be similar or
identical in some typefaces, and misrepresentation is possible because
Unicode
At 02:42 PM 2/7/2002 -0500, Elliotte Rusty Harold wrote:
At 11:34 AM -0800 2/7/02, Asmus Freytag wrote:
But, as the discussion shows, spoofing on the word level (.com
for .gov) is alive and well, and supported by any character set
whatsoever. For that reason, it seems to promise little gain to
Kenneth Whistler wrote:
The only widely-deployed alternative approach I know of is
ETSI GSM 03.38 (used in mobile telephony),
A truly bizarre character set: it supports English, French,
mainland Scandinavian languages, Italian, Spanish with Graves, and
GREEK SHOUTING.
--
John Cowan
I note that companies like Verisign already claim to offer domain names
in dozens of languages and scripts. Apparently these are converted by
something called RACE encoding to ASCII for actual use on the internet.
Does anyone know anything about RACE encoding and its properties?
:[EMAIL PROTECTED]]On
Behalf Of Tom Gewecke
Sent: Thursday, February 07, 2002 3:20 PM
To: [EMAIL PROTECTED]
Subject: Re: Unicode and Security: Domain Names
I note that companies like Verisign already claim to offer domain names
in dozens of languages and scripts. Apparently these are converted
At 01:21 PM 2/7/02 -0500, Elliotte Rusty Harold wrote:
I'm not sure Unicode can be fixed at this point. The flaws may be too
deeply embedded. The real solution may involve waiting until companies and
people start losing significant amounts of money as a result of the flaws
in Unicode, and
On Thu, 7 Feb 2002, Elliotte Rusty Harold wrote:
Trust is a human question decided by human beings, not a boolean answer
that comes out of a computer algorithm. I can trust that the message I'm
replying to came from a person named Barry Caplan even if I have no
proof of that whatsoever.
Or
At 04:17 AM 2/8/2002 +0330, Roozbeh Pournader wrote:
On Thu, 7 Feb 2002, Elliotte Rusty
Harold wrote:
Trust is a human question decided by human beings, not a boolean
answer
that comes out of a computer algorithm. I can trust that the message
I'm
replying to came from a person named Barry
Title: Message
What makes me
think you exist, anyway? ;^)
- rick (or so
I say)
-Original Message-From: Barry Caplan
[mailto:[EMAIL PROTECTED]] Sent: Thursday, 7 February 2002
17:13To: Unicode ListSubject: Re: Unicode and
SecurityAt 04:17 AM 2/8/2002 +0330, Roozbeh
At 4:31 PM -0500 2/7/02, James E. Agenbroad wrote:
Thursday, February 7, 2002
Would making the about to be misled respondent type the address of the
intended person (with a roman 'o', not a greek omicron) and then having
the system see if they match
At 5:12 PM -0800 2/7/02, Barry Caplan wrote:
On what basis can Elliotte know that a message purported to be from
Barry Caplan actually is from Barry Caplan, or that there even is
a Barry Caplan? The person writing this, who claims to be Barry
Caplan, has never met anyone named Elliotte Rusty
At 10:21 AM 2/7/02, Elliotte Rusty Harold wrote:
I don't like that solution, but not liking it doesn't mean it ain't gonna
happen as soon as Exxon loses a few billion dollars because somebody
spoofed them and thereby gained access to their bidding plans for oil leases.
Enron lost a few billion
division, instead of Trojans 'R Us.
I think that rather than coming to the Unicode list to
proclaim Unicode is a security risk! The sky is falling!
the better way to conceive this is that globalization of the
IT infrastructure of the world is a difficult business that
presents many new possibilities
[EMAIL PROTECTED] observed:
Analogously, people will keep opening executable attachments promising sex,
regardless of whether the 's', 'e', and 'x' are Latin letters or not.
They're not, of course: U+0455 U+0435 U+0445
-Doug Ewell
Fullerton, California
(address will soon change to dewell
On Wednesday, February 6, 2002, at 11:12 AM, Lars Kristan wrote:
Maybe digitally signed messages and bank accounts are not that good of an
example, since people would be more careful there. Another case where this
may get exploited will be domain names, once Unicode is allowed there.
While
]]
Sent: Wednesday, February 06, 2002 01:54
To: Unicode List
Subject: Re: Unicode and Security
At 09:39 2/5/2002, John H. Jenkins wrote:
Y'know, I must confess to not following this thread at all.
Yes, it is
impossible to tell from the glyphs on the screen what
sequence of Unicode
Well, nothing wrong with Unicode of course. Just means that there will
need
to be an option in your browser to reject any site without a digital
certificate, and perhaps it will need to be turned on by default. So,
Nothing prevents sites running frauds to get a certificate matching their
On Wed, Feb 06, 2002 at 07:12:19PM +0100, Lars Kristan wrote:
Well, I was tempted to join the discussion for a while now, but one of the
things that stopped me was that I didn't quite understand why it was so
focused on the bidi stuff.
Because it can have a dramatic effect, whereas changing
At 11:54 AM 2/6/2002 -0700, John H. Jenkins wrote:
The original focus was on digital signatures, and I still don't get the
objection. Because I don't know *precisely* what bytes Microsoft Word or
Adobe Acrobat use, do I refuse to sign documents they create? Is that the
idea? I mean, good
On Tue, Feb 05, 2002 at 01:27:49PM +0900, Gaspar Sinai wrote:
Talking about characters: I think bi-di should not be in
Unicode Standard because it is not a character.
It is an algorithm.
Why would that fix the problem? Then everyone would just choose their
own algorithim, and instead of a
At 13:27 +0900 2002-02-05, Gaspar Sinai wrote:
Just because some companies who have influence on Unicode
Consortium use some algorithm, like backing store and re-mapping,
it does not mean that this is the only way. And I don't even
think they do in cases when character conversion is
Gaspar Sinai has a valid point insofar as there is a possible
ambiguity in bidi text. However, he is absolutely wrong in
blaming the Unicode bidi algorithm for this problem.
Gaspar Sinai had written:
change products or to change the standard and use
a reversable bidi.
and later:
Hold on
Y'know, I must confess to not following this thread at all. Yes, it is
impossible to tell from the glyphs on the screen what sequence of Unicode
characters was used to generate them. Just *how*, exactly, is this a
security problem?
==
John H. Jenkins
[EMAIL PROTECTED]
[EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I don't see why pick on bidi. Unicode rendering is not reversible in
Latin too - from the rendering you cannot and should not be able to
tell whether a character was decomposed or precomposed.
Looking at some text, you would not be able to tell
Gaspar Sinai scripsit:
So common language is screenshots... Ok. I updated the page.
Thank you.
Now the exact same file is viewed with two different viewers
at the bottom of this page:
http://www.yudit.org/security/
Outlook Express, at least the version you are using, has a bug;
it is
On 04-02-2002 11:15:25 John Cowan wrote:
Outlook Express, at least the version you are using, has a bug;
it is failing to set the overall directionality to RTL even
though the first character is strongly RTL. The fact that
some implementations are buggy is hardly an argument against
either the
On Mon, 4 Feb 2002, John Cowan wrote:
Gaspar Sinai scripsit:
Now the exact same file is viewed with two different viewers
at the bottom of this page:
http://www.yudit.org/security/
Outlook Express, at least the version you are using, has a bug;
it is failing to set the overall
Gaspar Sinai...
Pursuing this kind of trivia hunt for bugs in an environment employing
Unicode is not any different than prusuing the same kind of bugs in any
other environment.
It is within the purview of the security community to find such bugs
before hackers find them.
But those bugs
Hello,
Before you call this thread a waste of time, and out of curiosity.. what
were theconsiderations put forth which determined the way the
bidi
algorithm is (uax#9). Ie. what were the pros and cons of a reversible
bidi?
Also, who make up the 'bidi community'? The users or the
On Mon, 4 Feb 2002, Mark Davis wrote:
Outlook Express, at least the version you are using, has a bug;
This is not a bug; it is specifically cited in the Bidirectional
Conformance section of Chapter 3 as one of the ways a higher-level
protocol can override the BIDI algorithm. I otherwise
Gaspar Sinai scripsit:
Hold on there! You admit that unicode alrgorithm is *really*
not reversable? I was just bluffing because I just saw that their
is no reverse algorithm published in the standard!
It can't be reversable, as my little English = CIBARA demonstration
showed. The only way
This thread is a waste of time.
Gaspar If unicode bi-di algorithm was reversable none of this would
Gaspar happen. Software developers, who are flash and blood people, would
Gaspar be able to do a clean room implementation of the algorithm and the
Gaspar reverse of it. The
No Real World document is going to make sense read both ways.
It will make sense one way, thus: "BARA-LA AW MALSI-AL mean
the Arabs and Islam respectively". The other order will make
no sense at all.
Good style might say to put in a line break so you know what's going on.
I don't know if that
Gaspar wrote:
The BIDI algorithm is not reversible, and could not be made reversible
without eliminating features that are important to the bidi community.
This was considered at the time the bidi algorithm was developed.
Hold on there! You admit that unicode alrgorithm is *really*
not
On Mon, 4 Feb 2002, Mark Leisher wrote:
[...cut some stuff to save room...]
I don't understand your reasoning. Applying the bidi algorithm or a
higher-level protocol does not change the backing store. Applying the bidi
algorithm is essentially a one-way transformation, but the original
From: Gaspar Sinai [EMAIL PROTECTED]
If the standard wants me to confuse the user, I would
rather dump the standard than comply.
Well, don't let the door hit you in the a** on the way out?
Te users will be less confused than you realize -- only people who walk in
with agendas see the flaws
At 02:15 PM 2/3/2002 +0900, you wrote:
On Sat, 2 Feb 2002, David Starner
wrote:
[...several lines cut to save room...]
I think I'm missing your perspective. To me, these are minor quirks.
Why
do you see them as huge problems?
I am thinking about electronically signed Unicode text documents
that
On Sun, 3 Feb 2002, Asmus Freytag wrote:
The bidi algorithm is anything but vague. Any
implementation can be rigorously tested against two
reference implementations, to ensure fully compatible
implementation.
Sorry buys to be this short this time but
I kicked life to my Windows laptop and
On Sun, 3 Feb 2002, John Cowan wrote:
Gaspar Sinai scripsit:
The following page contains my view of Unicode
BIDI algorithm (with screenshots).
http://www.yudit.org/security/
Oooo-kay. This is not a Unicode problem per se: it is about
embedded text vs. text that is not embedded.
Gaspar Sinai scripsit:
The following page contains my view of Unicode
BIDI algorithm (with screenshots).
http://www.yudit.org/security/
Oooo-kay. This is not a Unicode problem per se: it is about
embedded text vs. text that is not embedded. The Yudit and
IE versions are displaying a text
Gaspar Sinai scripsit:
So it is perfectly ok? I can make a non-ebedded example too.
I do not have time to make childish examples and screenshots
to get through my point. I have a job to do and text processing
is just my hobby.
Mine too, but it's difficult to understand the merits of an
On Sun, 3 Feb 2002, John Cowan wrote:
Gaspar Sinai scripsit:
So it is perfectly ok? I can make a non-ebedded example too.
I do not have time to make childish examples and screenshots
to get through my point. I have a job to do and text processing
is just my hobby.
Mine too, but
On Mon, Feb 04, 2002 at 02:25:05PM +0900, Gaspar Sinai wrote:
And the bottom line is: I don't really care if
Unicode will admit that this is a problem. If
my reasoning (not my screenshots) convince
*some* people not to sign electronically unicode
text I think I did those guys good - and that
A while back there was some discussion of security. You could start by
checking the list archies for those threads.
Is Unicode secure? What character standards can be
considered secure?
What does security really mean for a character encoding?
In my opinion, security is related to bugs in
On Sun, Feb 03, 2002 at 11:41:11AM +0900, Gaspar Sinai wrote:
I had the following problems where unicode could not
be used because of security issues. In all cases
the signer of a document can be lured into
believing that the wording of the document he/she
is about to sign is different.
On Sat, 2 Feb 2002, David Starner wrote:
[...several lines cut to save room...]
I think I'm missing your perspective. To me, these are minor quirks. Why
do you see them as huge problems?
I am thinking about electronically signed Unicode text documents
that are rendered correctly or believeed
On Sun, Feb 03, 2002 at 02:15:51PM +0900, Gaspar Sinai wrote:
I am thinking about electronically signed Unicode text documents
that are rendered correctly or believeed to be rendered correctly,
still they look different, seem to contain additional or do not
seem to contain some text when
90 matches
Mail list logo
