Hi Henry
I dont think user cancelled is the appropriate error code. This should
only be used when the user wishes to abort an existing SSL connection.
However, that would not result in the browser asking the user to select
a different certificate next time since aborting a current connection is
not related necessarily to choosing the wrong certificate.
If the server replies with an error below indicating that the user
certificate is faulty, then the browser should inform the user and ask
him to pick another certificate.
Note that the certificate might be perfectly OK, but simply not trusted
by a particular SP (e.g. unsupported certificate), in which case the
certificate should not be marked as bad by the browser.
regards
David
Henry Story wrote:
> On 2 Sep 2010, at 13:15, Henry Story wrote:
>>> Duh! I forgot to give you the URL for the code: http://github.com/bblfish/TLS_test>>>> There is really only just one class that starts the server and deals with incoming requests.
>>>>http://github.com/bblfish/TLS_test/blob/master/src/main/java/net/bblfish/test/SSLTestServer.java>>>> Prof. Chadwick pointed out to me that
>>>>> Yes there are a set of standard error messages that can be sent (by either the browser or the server). These include
>>>>>> bad_certificate(42),
>>> unsupported_certificate(43),
>>> certificate_revoked(44),
>>> certificate_expired(45),
>>> certificate_unknown(46),
>> These are listed here
>>http://tools.ietf.org/html/rfc4346#section-7.2>> The codes are described in a little more detail here
>>http://tools.ietf.org/html/rfc4346#section-7.2.2>> bad_certificate
> A certificate was corrupt, contained signatures that did not
> verify correctly, etc.
>> unsupported_certificate
> A certificate was of an unsupported type.
>> certificate_revoked
> A certificate was revoked by its signer.
>> certificate_expired
> A certificate has expired or is not currently valid.
>> certificate_unknown
> Some other (unspecified) issue arose in processing the
> certificate, rendering it unacceptable.
>>> These explanations are not very detailed. Could it be that what we need is the
>> user_canceled
> This handshake is being canceled for some reason unrelated to a
> protocol failure. If the user cancels an operation after the
> handshake is complete, just closing the connection by sending a
> close_notify is more appropriate. This alert should be followed
> by a close_notify. This message is generally a warning.
>> signal?
>>> It would be good to know if there is any type of requests that should result in the user being asked to choose a new certificate. Clearly if the certificate is expired one would at the minimum expect the browser not to automatically send the same one back. The same for user_cancelled...
>>>> I suppose that this is exactly what throwing those exceptions in Java generates. You can choose which exception you wish the server to throw at the next connection (after the session has been closed) by selecting it on the resulting form.
>>>> I think we can use this to generate clear bug reports to the browser makers with a test case. Please let me know what results you get on browsers on your OS, or of course if there are bugs in the code, improvements that could be made, etc...
>>>> Henry
>>>> On 1 Sep 2010, at 18:41, Henry Story wrote:
>>>>> Hi,
>>>>>> I have put together a little github java project to help us explore the logout problem. We can use this to file bug reports to the browser vendors. This is just a first attempt to explore the space with a minimal jetty browser. The README explains how it works.
>>>>>> What I have found so far could be useful:
>>> - Chromium and Safari on OSX can be gotten to ask for a new certificate
>>> - Firefox and Opera cannot. Even if the server tells them the certificate is broken (I think that is what is being done by throwing the exception) those browser send the same certificate. That is clearly an error, as even normal clients may choose by mistake an invalid certificate.
>>>>>> But perhaps there are other tools we should be using. Any ideas? Looking for SSL Experts to help out here :-)
>>>>>> Henry
>> Social Web Architect
>http://bblfish.net/>>
--
*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick at kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5
*****************************************************************