StreamSec and SSL

[colutti]

Guys

When i bought your components (i did it today) nobody told me that I also needed to spend $400 more in StreamSec components to be able to use https on my webserver.
On your home page, you guys mention that RTC is fully https compatible. Thats not all true, unless we buy StreamSec components.
What should I do? Spend $400 more to get StreamSec? Is this fair?

[D.Tkalcec (RTC)]

1) Can you please post the URL where you've read that the RTC SDK includes all the components you will ever need to write a SSL-based Web Server? If there is really such a statement, it is wrong and has to be changed. Thank you.

2) As far as I know, StreamSec Tools 2.1 (which is what you need to make a SSL-enabled Web Server using the RTC SDK) costs 99 EUR and not $400. Click HERE for SctreamSec Tools Order page and scroll down to StreamSec Tools 2.1.

3) In addition to SSL support through third-party encryption components (like StreamSec Tools 2.1), the RTC SDK also includes SSL support for the Client by using WinInet and WinHTTP APIs. In other words, you do not need anything extra to write SSL-enabled Clients with the RTC SDK.

4) In addition to using SSL encryption components as plugins (like StreamSec Tools 2.1), RTC SDK Server applications can also be compiled into ISAPI DLLs, which can be installed on third-party Web Servers with SSL support - like IIS, Apache and Abyss. Then you wouldn't need third-party encryption components, but you will need a third-party Web Server which has SSL support.

PS. Even though you could compile your Server-side code into ISAPI DLLs to run it under a third-party WebServer (like MS IIS or Apache) and rely on built-in SSL support for RTC Clients, I strongly recommend you to purchase StreamSec Tools 2.1 if you need to write a HTTPS (SSL/TLS-enabled) Web Server. I think the price for StreamSec Tools 2.1 (currently 99 EUR) is more than justified and the benefits you get from using the RTC SDK with StreamSec Tools 2.1 are well worth it.

Best Regards,
Danijel Tkalcec

[Henrick (StreamSec)]

When i bought your components (i did it today) nobody told me that I also needed to spend $400 more in StreamSec components to be able to use https on my webserver.

Like Danijel wrote, we (StreamSec) sell the required components for EUR 99. We also provide free newsgroup support at news://news.streamsec.net.

OTOH, if you also want technical level 2 support via email the cost is EUR 400 per year, which IMHO is a fair price.

[colutti]

1) Can you please post the URL where you've read that the RTC SDK includes all the components you will ever need to write a SSL-based Web Server? If there is really such a statement, it is wrong and has to be changed. Thank you.

I did not read it. You did not say that the RTC SDK includes all the components I will ever need to write a SSL-based Web Server, but you guys also did not mention that it only works with SSL if you buy another component. I think it should me mentioned somewher, like this:

"Write http and https webservers .. bla bla bla bla" *
* https only available if you purchase StreamSec Tools

2) As far as I know, StreamSec Tools 2.1 (which is what you need to make a SSL-enabled Web Server using the RTC SDK) costs 99 EUR and not $400. Click HERE for SctreamSec Tools Order page and scroll down to StreamSec Tools 2.1.

I did not know that. But, still, I will have to spend 99 EUR.

3) In addition to SSL support through third-party encryption components (like StreamSec Tools 2.1), the RTC SDK also includes SSL support for the Client by using WinInet and WinHTTP APIs. In other words, you do not need anything extra to write SSL-enabled Clients with the RTC SDK.

I do not care about the client. I am building an webserver.

4) In addition to using SSL encryption components as plugins (like StreamSec Tools 2.1), RTC SDK Server applications can also be compiled into ISAPI DLLs, which can be installed on third-party Web Servers with SSL support - like IIS, Apache and Abyss. Then you wouldn't need third-party encryption components, but you will need a third-party Web Server which has SSL support.

I am building a standalone webserver.

PS. Even though you could compile your Server-side code into ISAPI DLLs to run it under a third-party WebServer (like MS IIS or Apache) and rely on built-in SSL support for RTC Clients, I strongly recommend you to purchase StreamSec Tools 2.1 if you need to write a HTTPS (SSL/TLS-enabled) Web Server. I think the price for StreamSec Tools 2.1 (currently 99 EUR) is more than justified and the benefits you get from using the RTC SDK with StreamSec Tools 2.1 are well worth it.

I dit not say that i dont get benefits from using the RTC SDK with StreamSec Tools 2.1. I am not saying that StreamSec is good or bad. I just wanted to know before I buy RTC that i needed also to buy StreamSec Tools.

Best Regards,
Danijel Tkalcec

[D.Tkalcec (RTC)]

I'm sorry, but it is incorrect to say that HTTPS is only available if you purchase StreamSec Tools. As I've already mentioned above, the RTC SDK has built-in SSL support for the Client side and you can also compile RTC Server-side code into ISAPI DLLs to get SSL support for the Server side.

Anyway ... there was a statement on the "RTC SDK About" page which said something like "Use third-party encryption components (StreamSec Tools 2.x) to add SSL/TLS support to your RTC Clients and Servers." before you've purchased a PRO RTC SDK subscription, but in hope to avoid further misunderstanding, I have extended that statement to:

"When you need strong SSL/TSL encryption, you can either use 3rd-Party Encryption components as plug-ins for the RTC SDK (for example: StreamSec Tools 2.1 = 99 €), or you can use built-in SSL support with RTC Clients and compile your RTC Server code into ISAPI DLLs to run on third-party Web Servers which have SSL support (for example MS IIS, Apache or Abyss)".

I know this does not solve your current problem, but I am afraid I can not change the past to inform you about this requirement BEFORE you've made your purchase. If you still think there is a problem, please let me know what you think I should do now to resolve it. I just hope you don't think the web pages were designed with the intent to mislead you into thinking something that is not.

Best Regards,
Danijel Tkalcec