Re: [twsocket] Poll 2 - Host/SNI support in web server

2017-03-02 Thread François Piette
> But should we now add proper host site support to the web server component
itself, so these settings can 
> be made at design time if necessary, with simplified application code?

That would be useful.
Implementation must be sure to work without any site support data configured
for a single site as it is now.

--
francois.pie...@overbyte.be
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be




-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be


[twsocket] Poll 2 - Host/SNI support in web server

2017-03-02 Thread Angus Robertson - Magenta Systems Ltd
With IPv4 address scarcity, most web servers have multiple hosts
supported using a single IP address, adding a Host: header to each
request header, and using SSL Server Name Indication (SNI) for SSL that
needs to know the host before a request is received.  

The ICS web server has always supported the Host: header, which can be
checked in the BeforeProcessRequest event as MyClient.RequestHostName,
while SNI can be checked in the SslServerName event as
MyClient.SslServerName.  

But currently this is not done automatically, applications are
responsible for adding code to check the host and changing the server
directories so pages for the correct host are served, and the correct
SSL context is selected with a matching SSL certificate.  

I did this recently for my public web server that uses ICS, the server
status page shows the four public hosts supported:

https://www.telecom-tariffs.co.uk/serverinfo.htm

It also reports the certificate chains using the new ValidateCertChain
function in V8.41.  

I created an array of records:  

   TSiteHost = record   
shHostName: string ;
shHostAliass: StringArray ;
shHostAliasTot: integer ;
shDesc: string ;
shBindings: StringArray ;
shBindingTot: integer ;
shDocDir: string ;
shTemplateDir: string ;
shDefaultDoc: string ;
shSslAllowed: boolean ;
shSslCertFileName: string ;
shSslPrivKeyFileName: string ;
shSslCAFileName: string ;
shSslPassPhrase: string ;
shSslSecLevel: integer ;
shWebLogDir: string ;
shSslCtx: TSslContext ;
shSslOK: boolean ;
shDomains: string ;
shCertInfo: string ;
shCiphers: string ;
shCertExiry: TDateTime ;
end;
TSiteHosts = array of TSiteHost;

which includes all the different information needed for each host site,
including the SSL context, which is loaded from settings.  
I added code to the SslServerName and BeforeProcessRequest events that
check for the host (or host alias) and change the context and site root
directories appropriately. 

I'm sure others have added something similar to their web server
applications. 

But should we now add proper host site support to the web server
component itself, so these settings can be made at design time if
necessary, with simplified application code?

As an aside, I used this to test ECC certificates and ciphers, you'll
notice that www2.telecom-tariffs.co.uk uses an ECDSA key instead of RSA,
with a different intermediate chain, and SSL connects with cipher
ECDHE-ECDSA-AES128-GCM-SHA256 instead of cipher
ECDHE-RSA-AES128-GCM-SHA256.  ECC keys are much shorter than RSA keys,
which means less traffic sending then when SSL connects.  

Angus



-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be