Subject: RE: Static Page after SSL Handshake Failure ??

From: [email-masked]
Date: Tue, 2 Jul 2002 10:14:35 +0100

I don't think you can. The handshake has to complete before any other data
can be transferred. An incomplete handshake means no connection and hence no
data.

However, I think you might be able to connect users with a lower cipher to a
different document root and from there direct them elsewhere. I recall this
being raised before, so look in the archive of this list.

Users of IIS will notice that the errors returned from server are becoming
more and more meaningless. "The page cannot be displayed" covers up whatever
the real error is.

I recommend using curl for testing anyway: http://curl.haxx.se

- 
John Airey
Internet systems support officer, ITCSD, Royal National Institute of the
Blind,
Bakewell Road, Peterborough PE2 6XU,
Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 [email-masked] 

Is the statement 'There is no such thing as truth'  true?

> -----Original Message-----
> From: Marc Buetikofer [mailto:[email-masked]]
> Sent: 02 July 2002 08:31
> To: [email-masked]
> Subject: Static Page after SSL Handshake Failure ??
> 
> 
> 
> 
> 
> Hi,
> 
> Is it possible for to return a static page to a browser if an SSL
> handshake failed? I have in mind the situation, when e.g. a 
> 56-bit Browser
> tries to hanshake with an Apache that requires 128 bits.
> I could not find any directive in the documentation.
> 
> Thanks for help!!
> 
>  Marc
> 
> ______________________________________________________________________
> Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
> User Support Mailing List                      [email-masked]
> Automated List Manager                            [email-masked]
> 

- 

NOTICE: The information contained in this email and any attachments is 
confidential and may be legally privileged. If you are not the 
intended recipient you are hereby notified that you must not use, 
disclose, distribute, copy, print or rely on this email's content. If 
you are not the intended recipient, please notify the sender 
immediately and then delete the email and any attachments from your 
system.

RNIB has made strenuous efforts to ensure that emails and any 
attachments generated by its staff are free from viruses. However, it 
cannot accept any responsibility for any viruses which are 
transmitted. We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email 
and any attachments are those of the author and do not necessarily 
represent those of RNIB.

RNIB Registered Charity Number: 226227

Website: http://www.rnib.org.uk 
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]

---

From: Thomas Binder <[email-masked]>
Date: Tue, 2 Jul 2002 12:35:46 +0200

Hi!

On Tue, Jul 02, 2002 at 10:14:35AM +0100, [email-masked] wrote:
> However, I think you might be able to connect users with a lower
> cipher to a different document root and from there direct them
> elsewhere. I recall this being raised before, so look in the
> archive of this list.

I've done this using mod_rewrite. For example, to redirect
browsers connecting with only export cipher strengths:

<Directory /path/to/special/directory>
SSLOptions +StdEnvVars
RewriteEngine on
RewriteCond %{ENV:SSL_CIPHER_EXPORT} "^true$"
RewriteRule ".*" /noexport.html [L]
</Directory>

Or to redirect browsers not connecting with at least 100 bit
effective key size:

<Directory /path/to/special/directory>
SSLOptions +StdEnvVars
RewriteEngine on
RewriteCond %{ENV:SSL_CIPHER_USEKEYSIZE} "!^[0-9]{3}"
RewriteRule ".*" /keytoosmall.html [L]
</Directory>

Note that the URIs you redirect to (here: /noexport.html and
/keytoosmall.html) have to live outside /path/to/special/directory
(or inside a subdirectory which has RewriteEngine off).

Of course, having StdEnvVars set for certain directories lowers
the performance, but I see no other way to check for cipher
parameters without letting the handshake fail.

Ciao

Thomas