How to determine if remote browser connected with HTTP only or with HTTPS/SSL?

[hoby]

Hello, Danijel... 

How can I determine if the remote browser connected via HTTP:// or HTTPS://?  I am using RTC with TSSLServerRtcCryptPlugin by ElDos/SecureBlackBox.  The SSL support is working fine, but I would like to enforce usage of HTTPS/SSL on certain page requests, such as via a redirect if they attempted to browse a certain page with HTTP:// instead of HTTPS://. 

Specifically, I would like to be able to determine this within a TRtcDataProvider's onDataReceived event.  Sorry, but I have searched the docs, source, forums, etc, like forever and can't seem to track this down.  Maybe I am just missing it somewhere?

This is probably quite simple and is just a newbie issue on my part, but can you give me some direction in this regard?

Thanks much... 

Hoby

[D.Tkalcec (RTC)]

Because your HTTPS (SSL) Server will be working on a different Port than your plain HTTP Server, you simply need to check the "Sender.LocalPort" or the "Sender.ServerPort" property if you want to know if the Client is connected to your Server by using plain HTTP, or HTTPS (HTTP over SSL). These properties will be available in all RTC events.

For example, if you are using standard Ports, your HTTP Server will be listening on Port '80' and your HTTPS (SSL) Server will be listening on Port '443'. Inside your "OnCheckRequest" and/or "OnDataReceived" event, you can check this by doing something like ...

Code:

if Sender.LocalPort='80' then // plain HTTP
  begin
  // Client is connected through HTTP
  end
else if Sender.LocalPort='443' then // HTTP over SSL
  begin
  // client is connected through HTTPS (SSL)
  end;

PS. I guess you are already using the "TRtcDualDataServerLink" component to link your TRtcDataProvider and TRtcServerModule components to both TRtcHttpServer components (HTTP and HTTPS). If not, then check the "QuickStart/DualServer" for an example. That example is also using the "Sender.ServerPort" property to print out the Port number where the Client is connected.

Best Regards,
Danijel Tkalcec

[hoby]

Thanks much for the response, Danijel. 

Actually, I am not using a standard port, especially not on a development system with so many web services running.  Sorry for the confusion.  However, I can't assume this app will listen on any specific port once it is deployed. 

Regardless, I am not providing two interfaces as you described, but just one interface that uses the crypt plugin.  Since I only want to support SSL based traffic, I do not want to provide a standard http (80) interface. 

So, really, I was actually more concerned that someone could bypass the crypt plugin functionality by simply diverting the browser port selection using something like "http://someserver:443/somepage".  Actually, I thought I had seen this type or redirection work during some testing, which is why I was concerned.  However, I can't seem to reproduce it now.  I must have been mistaken about what happened.

So, perhaps, the more appropriate question then would be, is it possible for someone to successfully access my server interface that uses the SBB SSL crypt plugin by using plain http with a redirected URL of that nature?  And if so, how could I tell that they were using http instead of https?  But, if that is not possible to bypass the plugin that way, then I guess the question is moot.

BTW, I saw in your email about the upcoming changes in RTC that StreamSec will be releasing a version that supports your unicode string changes.  Do you know if ElDos/SBB will be supporting that at some point soon as well?

Thanks much...

Hoby

[D.Tkalcec (RTC)]

When you use the "CryptPlugin" interface with TRtcHttpClient and TRtcHttpServer components, all communication will be going through the connected "CryptPlugin" component, without exception. There is no way for any Client to bypass this behavior.

Normally, a Server using a CryptPlugin component which implements SSL encryption should ONLY accept SSL encrypted communication (HTTPS). But since the implementation of a "CryptPlugin" interface is vendor-specific, you should contact your "CryptPlugin" component vendor (Eldos in your case) to make sure that their SSL encryption components and their implementation of the RTC "CryptPlugin" component don't allow a Client to bypass the encryption.

NOTE: There is a "DummyCryptPlugin" component included in the RTC SDK, which does NOT implement any kind of encryption, but simply returns any data received (unmodified). The "DummyCryptPlugin" component was included ONLY for the purpose of testing the CryptPlugin interface, it was not supposed to actually encrypt data. And my guess is that you have tested a Demo which was using this "DummyCryptPlugin" component. Because that implementation was always working with plain HTTP, you could do things like "http://myserver:443/" to communicate with the Server using plain HTTP, even if the "CryptPlugin" checkbox was checked. This should NOT be possible when using a "CryptPlugin" component which implements SSL Encryption.

Best Regards,
Danijel Tkalcec

[hoby]

Super.  Thanks for the help, Danijel.