Web Profile and security

Luigi Paioro luigi at lambrate.inaf.it
Fri Dec 17 06:04:44 PST 2010


> Jonathan said:
>> Does anyone have any experience setting up a HTTPS desktop app web server?
>> Does this not require much more work for the user to setup a HTTPS cert for
>> each desktop?
>
> Hopefully my previous message helped to clarify things, but to be direct,
> the user doesn't need a cert (nor does the hub).  The web app needs to supply
> the cert.  Thus, assuming we can get this to work, users will not need to do
> any special setup other than to install and run a Web-SAMP hub.
>
> cheers,
> Ray

Dear All,

   I would like to contribute to this discussion bringing my experience 
supporting TLC/SSL in SAMPy (Standard Profile).

As Ray has so clearly explained, the TLS/SSL connections can be 
established via a secure socket providing a certificate server side (the 
Hub), client side (the App) or both.

In the first case, once the client asks the server to open a new 
channel, the server returns a certificate which can be:

  a) signed by a certification authority (like VeriSign); in this case,
     the client can check whether the CA is listed within its well known
     trusted CAs and, in case, use the locally stored CA certificate
     to verify the server certificate sign;

  b) or self-signed; in this case the client can decide whether accept
     the certificate or not, and, in case, add the self-signed "CA" to
     the list of trusted CAs.

If the server is evaluated trusted, then a secure socket is opened. The 
secure socket guarantees that the communications (passing new through an 
HTTPS connection) are protected. This means that all communication 
between the App and the Hub are encrypted. Basing on this concept, in 
SAMPy I associated to an HTTPS channel (with certificate hub side only) 
an alternative method to authenticate the applications, that is 
exploiting the Basic Authentication. At registration time (which is an 
HTTP(S) POST from the client to the hub), the hub requests an user and 
password to the client in order to accept the registration. SAMPy hub is 
provided with a system which allows to record the acceptable users with 
their passwords (which are encrypted and locally stored in a well known 
file). I guess that in principle a similar mechanism can be used for the 
Web Profile as well. In this case the Hub can be provided with a default 
certificate used just to open a secure layer, while the client 
authentication is performed by requesting an user name and password to 
the end user; being, in practice, the browser the real client 
application, the TLS/SSL + Basic Authentication _should_ be supported by 
default. I say _should_, 'cause I don't really know Flash, Silverlight 
and Java Applets how would manage this case. In any case, a possible 
risk is that the end user, with distraction, might input the user and 
password even if the hub registration request is performed by a 
malicious client (pretty bad).


In the second case (certificate client side), the global mechanism is 
almost the same: the hub requires a certificate from the client, then 
checks whether it has been signed by a trusted Certification Authority 
(which must be within the list of CAs known by the Hub) and then accepts 
the connection or rejects it. A normal Standard Profile application can 
easily be provided with a certificate, but I don't know whether it is 
feasible for a Web Profile client (which runs locally without really 
having access to the local resources) or not. Maybe a system like that 
provided by the signed applets that Mark indicated in another mail can 
be used, but I'm not expert in this area.


The third case (both side certificates) is the sum of those above.


Said this, for the time being I still don't have a strong opinion about 
what could be a preferable approach with respect to those mentioned in 
the previous mails. Maybe I will have a clearer idea after prototyping a 
bit.

My two cents.

Regards,

   Luigi


More information about the apps-samp mailing list