First, Happy new year to all!!

Ok. Heres a quick question about HTTPS/SSL.

What we want to do is send messages using SOAP, but encrypted so as to prevent spoofing & fraudulent messages etc.
So, it occurred that HTTPS would be a good thing, as it's well established, must be pretty secure (banks use it for cc authentication).
But.. my boss reckons that theres too much overhead in using it in establishing the connection.

Now, I'm no expert with HTTPS, but I am assuming that there is an initial set of transactions to negotiate the link, after which a cookie (session_id or whatever) is set.
So I'm hoping that there will only be 1 long setup transaction then subsequent transactions within the session will still be encrypted, but faster.

So, if as long as https transactions occur within the session timeout period there shouldn't be a need to set the session up again.

This just HAS to be a better way than doing our own encryption on the message (doesn't it?)

What I'd like to know is if this is this a correct interpretation of what I've read about HTTPS so far?

Cheers,

Bruce

Been doing a bit of reading too ... and I get somewhat conflicting answers.  I did read one snippet that referred to "the overhead of encoding and decoding" and suggested that SSL be used only for the exchanges within a series for which security is vital, which kindof implies that it's the encoding rather than the (initial?) setup of an SSL connection that causes a performance hit.   Hmm - I'm not sure if that helps;  any way you can set up a benchmark test that will emulate your loadings under HTTP and then under HTTPS and see how it works in something close you your case?   Is your application all protocol / transfer and very little real work (in which case the efficiency could be an issue), or is there a substantial application with relatively small protocol exchanges (in which case any efficiency hits may go un-noticed in the grand scheme of things!)

Hi Graham,

Your last case applies.  I'm not working on this myself, but have done some legwork on it, and after we got SSL/HTTPS working, there doesn't seem to be a speed issue at all.. yet.  The level of load is about 0.5 short (<1k) messages a second. I'm sure with more load the cpu would have to do more work naturally.
I'm happy with it, but the powers that be are looking at other things like VPN or some other encryption.
I still think HTTPS is the way to go though.

Thanks again. It's nice to have someones opinion.

Bruce

---