Re: An attack on paypal
The problem with these stop crackers and hackers by law is that it allows
software developers to get away with leaving huge gaping security holes
unfixed. Anecodatal evidence: The classic well known Robin Hood and Friar
Tuck "hack".
These days, the bug wouldn't get fixed and the guys reporting it would
wind up in jail because they "convinced" the OS authors to fix the
bug. IMHO, not the right way to go at all.
from http://ftp.arl.mil/ftp/unix-wizards/V16%23017
scroll down a bit more than half way down the page (also available from
most other GNU sources)
Back in the mid-1970s, several of the system support staff at
Motorola discovered a relatively simple way to crack system
security on the Xerox CP-V timesharing system. Through a simple
programming strategy, it was possible for a user program to trick
the system into running a portion of the program in `master mode'
(supervisor state), in which memory protection does not apply. The
program could then poke a large value into its `privilege level'
byte (normally write-protected) and could then proceed to bypass
all levels of security within the file-management system, patch the
system monitor, and do numerous other interesting things. In
short, the barn door was wide open.
Motorola quite properly reported this problem to Xerox via an
official `level 1 SIDR' (a bug report with an intended urgency of
`needs to be fixed yesterday'). Because the text of each SIDR was
entered into a database that could be viewed by quite a number of
people, Motorola followed the approved procedure: they simply
reported the problem as `Security SIDR', and attached all of the
necessary documentation, ways-to-reproduce, etc.
The CP-V people at Xerox sat on their thumbs; they either didn't
realize the severity of the problem, or didn't assign the necessary
operating-system-staff resources to develop and distribute an
official patch.
Months passed. The Motorola guys pestered their Xerox
field-support rep, to no avail. Finally they decided to take
direct action, to demonstrate to Xerox management just how easily
the system could be cracked and just how thoroughly the security
safeguards could be subverted.
They dug around in the operating-system listings and devised a
thoroughly devilish set of patches. These patches were then
incorporated into a pair of programs called `Robin Hood' and `Friar
Tuck'. Robin Hood and Friar Tuck were designed to run as `ghost
jobs' (daemons, in UNIX terminology); they would use the existing
loophole to subvert system security, install the necessary patches,
and then keep an eye on one another's statuses in order to keep the
system operator (in effect, the superuser) from aborting them.
One fine day, the system operator on the main CP-V software
development system in El Segundo was surprised by a number of
unusual phenomena. These included the following:
* Tape drives would rewind and dismount their tapes in the
middle of a job.
* Disk drives would seek back and forth so rapidly that they
would attempt to walk across the floor (see {walking drives}).
* The card-punch output device would occasionally start up of
itself and punch a {lace card}. These would usually jam in
the punch.
* The console would print snide and insulting messages from
Robin Hood to Friar Tuck, or vice versa.
* The Xerox card reader had two output stackers; it could be
instructed to stack into A, stack into B, or stack into A
(unless a card was unreadable, in which case the bad card was
placed into stacker B). One of the patches installed by the
ghosts added some code to the card-reader driver... after
reading a card, it would flip over to the opposite stacker.
As a result, card decks would divide themselves in half when
they were read, leaving the operator to recollate them
manually.
Naturally, the operator called in the operating-system developers.
They found the bandit ghost jobs running, and X'ed them... and were
once again surprised. When Robin Hood was X'ed, the following
sequence of events took place:
!X id1
id1: Friar Tuck... I am under attack! Pray save me!
id1: Off (aborted)
id2: Fear not, friend Robin! I shall rout the Sheriff
of Nottingham's men!
id1: Thank you, my good fellow!
Each ghost-job would detect the fact that the other had been
killed, and would start a new copy of the recently slain program
within a few milliseconds. The only way to kill both ghosts was to
kill them simultaneously (very difficult) or to deliberately crash
the system.
Finally, the system programmers
Re: An attack on paypal
> IE checks the server name against each CN's individually. I found that by experimentation too. I have VBScript sample on how to generate such a CSR request for IIS using the CryptoAPI. Furthermore, IE does not care if the CNs have different domains. e.g. /CN=www.domain.com/CN=www.domain.net/CN=www.domain.org -or even- /CN=www.domain.com/CN=www.cypherpunks.com/CN=www.microsoft.com You can self-sign such a cert with OpenSSL just fine. Whether you can get a real CA to sign such a thing is another matter. Adam - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Session Fixation Vulnerability in Web Based Apps
http://www.acros.si/papers/session_fixation.pdf "A Jobless Recovery is like a Breadless Sandwich." -- Steve Schear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Keyservers and Spam
At 8:58 AM -0700 6/12/03, David Honig wrote: >At 05:47 PM 6/11/03 -0700, Bill Frantz wrote: >>To try to reflect some of David's points with a real-world situation. I >>was at work, with a brand new installation of PGP. I wanted to send some >>confidential data home so I could work with it. However I didn't have my >>home key at work, so I didn't have a secure way to send either the data, or >>the work key. I didn't even have the fingerprint of the home key. >> >>My solution was to pull Carl Ellison's business card out of my pocket. It >>had his key fingerprint on it, and I remember getting it directly from him, >>so I could trust the fingerprint. Now Carl had signed my key, so when I >>downloaded it from the key server, I could verify that it was indeed mine >>(to the extent I trusted Carl). Carl's signature, and the key server >>allowed me to bootstrap trust into my own key. >> >> >>But with a key server, I didn't have to bother Carl to send me my key. Or >>depend on him being online when I needed it. > >True, although: >1. you could have had your own key-fingerprint on your own bizcard >and done the same. I didn't. I do now. >2. you needn't have had your valid email address there (going back >to the spam-thread), perhaps just your regular name. In fact you >could have your key on your home server, not in a public >server which serves as spambait. I don't think key servers are a significant cause of email address leakage compared with posting to open mailing lists, so I am not compelled by the original reason for this thread. >3. I think you also trusted that Carl has not been compromised >and re-signed a bogus key *after* he first signed it. (Not picking >on Carl here :-) Yup. And I could have followed Jill's suggestion of using symmetric encryption had I thought of it. Get a pass phrase from /dev/random and write it down. Put the piece of paper in my wallet and take it home. Decrypt the data and burn the paper. That's enough protection for low level commercial secrets. Cheers - Bill - Bill Frantz | Due process for all| Periwinkle -- Consulting (408)356-8506 | used to be the | 16345 Englewood Ave. [EMAIL PROTECTED] | American way. | Los Gatos, CA 95032, USA - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
--- "James A. Donald" <[EMAIL PROTECTED]> wrote: > -- > On 11 Jun 2003 at 20:07, Steven M. Bellovin wrote: > > Let me point folk at http://www.securityfocus.com/news/5654 > > for a related issue. To put it very briefly, *real* > > authentication is hard. > > I don't think so. > > Verisign's authentication is notoriously worthless and full of > holes, yet very few attacks have been based on getting > certificates issued to wrong party, or on stealing poorly > defended and readily accessible certificates, even though that > is quite easy to do. On the whole PKI as used today is fairly useless. I mean just because Company A signed/issued me a key doesn't mean I'm a nice guy nor a legit business. All it means is I paid money to have another company sign my key. What *would* be more useful is a model of web-o-trust. E.g. you make up your own key. Then you import public keys from third-party auditors you trust. Overtime the auditors will visit the business and if they like it they will sign the key. So say you trust auditors A, B and C and I trust auditors B, C and D. Well chances are if company Z is good the will be audited by at least one of the auditors we have in common. Unfortunately there is easy corruption in this model so you would have to keep tabs on your auditor yourself. However, in this model it wouldn't cost money [hey everything net-related should cost money right?] and would actually be meaningful. Tom __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
-- On 11 Jun 2003 at 20:07, Steven M. Bellovin wrote: > Let me point folk at http://www.securityfocus.com/news/5654 > for a related issue. To put it very briefly, *real* > authentication is hard. I don't think so. Verisign's authentication is notoriously worthless and full of holes, yet very few attacks have been based on getting certificates issued to wrong party, or on stealing poorly defended and readily accessible certificates, even though that is quite easy to do. One of the scams described in the paper you cite was the old "www.e-go1d.com" scam, but done using paper, rather than the internet -- the scammers registered a company name similar that of a target company owning a large block of IP addresses, and printed letter head paper similar to that of the other company. The problem was not that authentication was hard. Passwords would have sufficed. Self signed public keys would have worked even better. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG NoFj3E7m34BUCZIG2feG13OK1W+zx+gF7GsDX+Fm 40IAMrSyeCwPFMzRybwYkgWLZ2JE97Ao595KgemVp - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
-- On 11 Jun 2003 at 16:11, Jeffrey I. Schiller wrote: > Oh, and btw, the form posting URL in my message wasn't even > https, it was just http. So all the futzing in the world with > https wouldn't help! If https provided an adequate substitute for shared secrets, it would help. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG B9cEiIa9s5fvgr0BsmE3D3+BgvAXXvyF1/xSIi0k 4m1RrAexqkSii4X39kqfzefd2laQEwFD0bhYHaELv - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
Yep, I deployed such a PKI here at MIT back in 1996. Today every student and most faculty and staff have certificates. It really does work, but unfortunately the support for them in the common browsers is quirky enough that we have our support fun! I can understand why commercial sites shy away. I have also been involved in efforts to get U.S. Higher Education to start deploying client certificates. The big problem there is that public key encryption appears to require more then the amount of clue that most computer administrators seem to have, so education is a real problem. -Jeff Nomen Nescio wrote: Jeffrey I. Schiller writes: Oh, and btw, the form posting URL in my message wasn't even https, it was just http. So all the futzing in the world with https wouldn't help! Of course it would help. Have you been following this discussion at all? The idea is to eliminate passwords as being of any value in getting access to PayPal or other ecommerce sites, by replacing them with client certificates. This implies using https or something cryptographically similar. pgp0.pgp Description: PGP signature
PKI not working
picked up from a ietf pkix mailing list posting: http://www.garlic.com/~lynn/aadsm14.htm#43 http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?Op enDocument -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
At 05:34 PM 6/11/2003 -0700, David Honig wrote: When I buy $20 of gas with non-bearer credentials (ie, credit card), the vendor does a real-time check on me. Seems fair/useful to be able to do same on them. I suppose eBay's feedback suffices... if their last N "feedbacks" are negative, I might go elsewhere. we sort of tried that ... however the financial justification sort of fell apart. the big thing about BBB is being able to trust some merchant that you have absolutely no knowledge about. However, the actual buying patterns are extremely skewed ... with well over 80 percent of the transactions either repeat or with some organization that there is other avenues of trust propagation and involving a very small number of very large merchants. The BBB model tends to work with higher value, infrequent transaction. The remaining online, merchant market segment not covered via other trust processes, tended to represent a small percentage of total transactions, spread over a very large population of very small merchants, and frequently low value. eBay is an attempt to provide an alternative delivery for such market segment and the issue is how does eBay operations break even financially on a BBB like offering. The first filter is to quickly catch major scamming operations ... and differentiate between the one-off transactions. -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
closed systems (was Re: SDSI/SPKI background)
At 09:56 PM 6/11/2003 -0700, Carl Ellison wrote: >It's also almost exclusively for a closed authorization >infrastructure, rather than an open naming infrastructure. Because of its predominant use in closed, often proprietary systems, standardization is of questionable value. As long as each closed system's vendors (usually 1) agree among themselves on structure format, they're happy. Most of the fielded implementations I have seen would not interoperate with each other, because the vendor took some shortcuts -- following RFC2693 faithfully, but getting creative with the structure (the draft). It worked for them - didn't cause any trouble. - Carl +--+ |Carl M. Ellison [EMAIL PROTECTED] http://world.std.com/~cme | |PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
certificates & the alternative view
I think you have put your finger right on the problem. Certificates, https, and the entire PKI structure were designed for an accountless world, but the problem is accounts. the other view ... is using a little information theory is that certificates are stale, static, read-only copy of information in the certificate authority's account record targeted for offline environments where the relying party has no access to the real authoritative agency responsible for the information. one of the things from the '90s, in the transition from offline to the start of a pretty much ubiquitous online world was trying to come up with things to put into certificates to justify their price. One of the attempts was extreme overloading of the certificate with large amounts of identity and privacy information, and furthermore you convince the public that they should pay for the privilege of having huge amounts of their privacy information sprayed all over the world. The fallback is to attempt to reduce as much as possible any information of actual value in a certificate and to not go around confusing identification with authentication. This was sort of the relying-party-only certificates from the financial community in the later part of the 90s don't put any information of any value what-so-ever in a certificate; just create these huge, very large bit patterns that were one hundred times larger than a typical payment transaction and require that these extremely large bit patterns had to be attached to every payment transactions sent back to the financial institution (which already had the original copy of all the information). From this is was possible to demonstrate a PKI infrastructure where every certificate was compressed to zero bytes. The horrible payload penalty and information/privacy leakage problem was ultimately addressed with zero byte certificates. They contained zero byte, stale, static, read-only copy of the information in the certificate authority's account record. -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Keyservers and Spam
At 05:47 PM 6/11/03 -0700, Bill Frantz wrote: >To try to reflect some of David's points with a real-world situation. I >was at work, with a brand new installation of PGP. I wanted to send some >confidential data home so I could work with it. However I didn't have my >home key at work, so I didn't have a secure way to send either the data, or >the work key. I didn't even have the fingerprint of the home key. > >My solution was to pull Carl Ellison's business card out of my pocket. It >had his key fingerprint on it, and I remember getting it directly from him, >so I could trust the fingerprint. Now Carl had signed my key, so when I >downloaded it from the key server, I could verify that it was indeed mine >(to the extent I trusted Carl). Carl's signature, and the key server >allowed me to bootstrap trust into my own key. > > >But with a key server, I didn't have to bother Carl to send me my key. Or >depend on him being online when I needed it. True, although: 1. you could have had your own key-fingerprint on your own bizcard and done the same. 2. you needn't have had your valid email address there (going back to the spam-thread), perhaps just your regular name. In fact you could have your key on your home server, not in a public server which serves as spambait. Your home server could be "unlisted" by using an alternate port. (I do this to get around ISP blocking, but then I'm not trying to publish papers on my home server.) Or use CGI, or a password mechanism, to deter spam-spiders. The point with spam and publishing your email address is that its like having a public physical storefront: anyone can pay the price of a cigarette to a stream of homeless people to clog your physical store. Or form a huge line if you have bouncers at the door. That's what having a public interface means. 3. I think you also trusted that Carl has not been compromised and re-signed a bogus key *after* he first signed it. (Not picking on Carl here :-) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
At 03:38 PM 6/11/03 -0600, Anne & Lynn Wheeler wrote: even before e-commerce, the real >BBB process was that people called up the BBB and got realtime information > i.e. it was an online, realtime process. > >the equiivalent for an online, internet paradigm (as opposed to something >left over from the offline email genre of at least 10--15 years earlier) >was that the browswer tab;e pf trusted entities were of online authorities >(as opposed to certificate manufacturing) and if you cared, you clicked >thru to the BBB and got realtime information about the merchant in question >(being equivalent to when people call the BBB to actually get some level of >real input as opposed to just a fuzzy comfort fealing). When I buy $20 of gas with non-bearer credentials (ie, credit card), the vendor does a real-time check on me. Seems fair/useful to be able to do same on them. I suppose eBay's feedback suffices... if their last N "feedbacks" are negative, I might go elsewhere. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
At 08:20 PM 6/11/2003 -0700, James A. Donald wrote: I think you have put your finger right on the problem. Certificates, https, and the entire PKI structure were designed for an accountless world, but the problem is accounts. or slightly more accurately doing authentication for accounts. the other is frequently confusing identification with authentication. the internet registries (both domain and ip-address) haven't been doing authentication ... but just some simple identification. there are situations where identification may quite orthogonal to whether or not you are the owner of the account in question. also, identification also tends to open up the whole can of worms around protecting privacy. as periodically stated (in reference to x9.59) thick blanket of encryption protecting privacy information is good, the information not being there at all is even better. -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
> "Matt Crawford" <[EMAIL PROTECTED]> writes: > >... Netscrape ind Internet Exploder each have a hack for > >honoring the same cert for multiple server names. Opera seems to honor at > >least one of the two hacks, and a cert can incorporate both at once. > > > > /C=US/ST=Illinois/L=Batavia/O=Fermilab/OU=Services > > /CN=(alpha|bravo|charlie).fnal.gov/CN=alpha.fnal.gov > > /CN=bravo.fnal.gov/CN=charlie.fnal.gov > > Just to clarify this, so you need a multivalued CN, with one containing the > expression "(a|b|c)" and the remaining containing each of "a", "b", and "c"? > Is it multiple AVAs in an RDN, or multiple RDNs? (Either of these could be > hard to generate with a lot of software, which can't handle multiple AVAs in > an RDN or multiple same-type RDNs). Which hack is for MSIE and which is for > Netscape? Each CN is in a single-element RDN as usual. Netscape honors only the first CN in the SubjectDN, but will treat it as a restricted regex (shell-like * wildcard, alternation and grouping). IE checks the server name against each CN's individually. This was mainly determined by experimentation. I think we did find a limit on how long that first regex could be, but I don't remember what it was. Longer than my example, but short enough that some of our bigger virtual-hosting servers were inconvenienced by it. Openssl has no qualms about multiple same-type components. You just have to use the somewhat documented 0.commonName = ... 1.commonName = ... 2.commonName = ... in the configuration file. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
> You can also use *.fnal.gov Yes, we know, but our in-house CA operator (me) won't issue such a certificate. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
Steven M. Bellovin wrote: > Let me point folk at http://www.securityfocus.com/news/5654 > for a related issue. To put it very briefly, *real* authentication is > hard. It may be that real authentication is hard, but the unbelievably sloppy practices of domain name registrars doesn't prove the case. Imagine if property ownership were recorded with the same degree of rigor. "I'm sorry, sir, but you don't own your house any more. We received a typewritten letter with your name on it saying you were transferring ownership to ShoppingMall Inc. The demolition teams are moving in, and I'm afraid you'll have to be out by Friday." Domain names are handled carelessly while real estate is not, due to many factors. Probably one of the main ones is the relative immaturity of the domain name system compared to the centuries of experience we have evolving mechanisms to deal with real property. Clearly the registrars are making little or no effort to authenticate domain name transfers at present. At one time you could specify that only messages signed with a given PGP key would authorize a transfer, but that precaution has apparently disappeared, no doubt due to lack of interest and the costs of support. Maybe this could be something that a registrar could use to differentiate itself from the many otherwise-identical competitors in the market: we won't let your domain names get stolen. What a novel concept. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
Jeffrey I. Schiller writes: > Oh, and btw, the form posting URL in my message wasn't even https, it > was just http. So all the futzing in the world with https wouldn't help! Of course it would help. Have you been following this discussion at all? The idea is to eliminate passwords as being of any value in getting access to PayPal or other ecommerce sites, by replacing them with client certificates. This implies using https or something cryptographically similar. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: SDSI/SPKI background
Hi Stefan, At 10:57 AM 6/10/2003 +0200, Stefan Mink wrote: >>Hi, > >I'm currently preparing courses about telecommunication security >architectures and protocols of which certificates are a main >building block for authentication and authorisation. > >I'm presenting the PKI/PMI-models with X.509 as mainly used >architecture today and PGP as the distributed model. > >I also want to present SDSI/SPKI but as far as I know, work in this >direction seems to have stopped: The IETF WG was closed and some >drafts weren't finished as RFCs. Nevertheless there are interesting >ideas which are worth showing in contrast to X.509. IETF work on SPKI/SDSI was stopped. We do not need to continue adding new protocols to the SPKI/SDSI family. There's one draft that should have gone on to RFC, but people were using it from the draft instead. It's my fault that we left it at that stage and didn't publish the RFC. That's still on my list of things to do :-) It seems that other work kept getting in the way. But the uses of SPKI/SDSI have continued. Check out http://theworld.com/~cme/html/spki.html for implementations of and research papers on SPKI/SDSI. There are a few other implementations that have not been publicized, as well. SPKI/SDSI doesn't lead to an industry like PKI and isn't a stand-alone product like PGP. It's a tool to be used within other products. It's also almost exclusively for a closed authorization infrastructure, rather than an open naming infrastructure. In fact, under SPKI/SDSI thinking, a global naming instructure is not a proper use of one's time and energy. This is doubtless why the PKI Vendors react with hostility toward SPKI/SDSI. > >I still have two open points which I couldn't resolve by searching >and reading: >* Are there other authorisation certificate standards besides > SDSI/SPKI? Yes. Check out KeyNote and PolicyMaker. There are links to those from my web page. There is also XACML and there is promised to be WS-Authorization. Of course, you don't have to use certificates for authorization. You can bind an authorization to a key in a protected database (a key-based ACL, in SPKI/SDSI terminology). Samples of that are SSH and X9.59. >* What are the main reasons that work on SDSI/SPKI stopped although > much work was already done? We went on to use it in products and research. We were and are a group of developers and researchers, not standards writers. Standards writing is fundamentally boring. > > tschuess > Stefan >-- >Stefan Mink, Schlund+Partner AG (AS 8560) >Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 >F0D4 D2BA > Tschüss, Carl +--+ |Carl M. Ellison [EMAIL PROTECTED] http://world.std.com/~cme | |PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
"Matt Crawford" <[EMAIL PROTECTED]> writes: >True as written, but Netscrape ind Internet Exploder each have a hack for >honoring the same cert for multiple server names. Opera seems to honor at >least one of the two hacks, and a cert can incorporate both at once. > > /C=US/ST=Illinois/L=Batavia/O=Fermilab/OU=Services > /CN=(alpha|bravo|charlie).fnal.gov/CN=alpha.fnal.gov > /CN=bravo.fnal.gov/CN=charlie.fnal.gov Just to clarify this, so you need a multivalued CN, with one containing the expression "(a|b|c)" and the remaining containing each of "a", "b", and "c"? Is it multiple AVAs in an RDN, or multiple RDNs? (Either of these could be hard to generate with a lot of software, which can't handle multiple AVAs in an RDN or multiple same-type RDNs). Which hack is for MSIE and which is for Netscape? Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
-- On 10 Jun 2003 at 23:26, Anonymous wrote: > In short, if Palladium comes with the ability to download > site-specific DLLs that can act as NCAs, it should allow for > solving the spoofed-site problem once and for all. When you > login to paypal or e-gold, you would authenticate yourself > using a cert that only those sites could see. This can be > done in the framework of standard SSL, but would require a > Palladium-aware browser. Well, this would work just great provided the browser was made palladium aware in such a way as to be useful to the user, rather than to verisign. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG VBdyipPLv5JzjJ0eIFxxeMDsO30Us9Mvs7lmm2ka 4R5+YjVhKptjgGIVZsjTfX5nDogjTf2G8x7fRhKmN - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The real problem that https has conspicuously failed to fix
-- On 10 Jun 2003 at 21:33, Anne & Lynn Wheeler wrote: > certificates were originated to address a specific issue with > key distribution and trust involving parties that 1) had no > prior business relation, 2) were unlikely to have any future > business relationship, and 3) didn't have online access to > trusted 3rd party. however, it is actually much more natural > in a standard business process setting that public key is > registered in lieu of shared-secret authentication material > when parties are involved that have established business > relationship (aka for example a person with some sort of an > account, especially in any sort of online paradigm). A > trivial examples is certificateless operation with > public/private keys for radius, kerbers pk-init or x9.59 > standard for all retail payment transactions (internet, > non-internet, point-of-sale, debit, credit, ach, > stored-value, etc). I think you have put your finger right on the problem. Certificates, https, and the entire PKI structure were designed for an accountless world, but the problem is accounts. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG DxVY4Z01oFU7xvn07JDMoJBGMxVLt61s4VcQTMLB 4v46MbB1PtOjOaOcNvexHiyB1LzfD0RJ+CIPtD7RD - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
