[531] in WWW Security List Archive
SSL security
daemon@ATHENA.MIT.EDU (Wenbo Mao)
Thu Mar 23 17:01:30 1995
From: Wenbo Mao <wenbo@wenbomao.hpl.hp.com>
To: ssl@netscape.com
Date: Thu, 23 Mar 95 17:29:17 GMT
Cc: www-security@ns2.rutgers.edu, wm@hplb.hpl.hp.com,
vishnu%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Errors-To: owner-www-security@ns2.rutgers.edu
Dear Sir,
In the electronic commerce area, SSL indicats an important piece of
security work. I do appreciate it. Here I enclose my questions to the
SSL protocol. I send them to you because I couldn't find answers from
the FAQs of SSL.
1) The protocol specifies security enhanced communications between
a client and a merchant. From my understanding of the protocol
(version: RFC of Feb 9th 1995), the identity of the merchant is always
authenticated and that of the client is optionally authenticated.
Will this optional authentication of the client form a security
hole in that there are opportunities to masquerade a client? In the
attack analysis provided in Appendix D of the RFC, I cannot see you
have any analsis of this threat. Why not?
2) I assume that the protocol is proposed mainly for enhancing a web
browser into an electronic commerce tool (that's why I use "merchant"
instead of "server" as you phrased). Thus, payment transactions are
inevitable. Has the protocol specified any mechanism to facilitate an
electronic payment transaction? Where? When I speak of electronic
payment transaction, I refer to the situation where the payer's
signature is not physical, but digital. We need the payer to sign a
payment order in order to prevent repudiation. How is this done in
SSL?
3) Let me anticipate your answer to the last question in (2) to be:
"the optional authentication to the client (the payer in most cases)
requires (s)he to digitally sign a session key, ie, the so-called
client-write (=merchant-read) key, and then any payment order
encrypted by that key is bona fide." I answer my question this way
because SHTTP also *optionally* uses this solution. My problem with
such a "bona-fide-ness" is as follows: since the session key is
symmetric, the client can dispute (after a transaction) that it is the
merchant who has forged the payment order. The merchant can easily do
so, right?
4) Encryptions between a pair of client and merchant are chained by
a "sequence number". How many sequence numbers a client (a merchant)
should maintain? Will a web browser implemented this way have any
fault tolerance? Imagine a communication corruption; the result:
one party updated the sequence number while the other did not.
Will this be chaotic?
Please correct my misunderstanding. Many thanks!
With best regards,
Wenbo Mao
+===============================================================+
| Hewlett-Packard Labs | +44 (0)117 922 9528 (voice) |
| Filton Road | +44 (0)117 922 8924 (fax) |
| Stoke Gifford | Email: wm@hplb.hpl.hp.com |
| Bristol | WWW URL: http://wenbomao.hpl.hp.com |
| BS12 6QZ | Privacy enhancement: get my public key |
| UK | by finger wenbo@wenbomao.hpl.hp.com |
+===============================================================+
