Encrypting data vs using HTTPS?

[Richard L Rosenheim]

Anyone care to express their two cents over pros and cons of encrypting the
data being transmitted (within the SOAP package) versus just utilizing a
HTTPS connection?

Richard Rosenheim

[Keenan Newton]

My experiences are that from a performnace stance they are about the
same. However, I thought encrypting the SOAP message was simplier.
not to mention using HTTPS is also transport specific. If you want to
use a different protocol such as TCP. Then you are going to need
another mechanism for encrypting your transmissions. I think
eventually the development community will realize sending SOAP messages
via HTTP does not perform well, and maybe using a simplier protocol
like say TCP would be more efficient. My suggestion is to encrypt the
SOAP package that way your encryption is independent of the transport
mechanism you are sending you SOAP messages on

[Rafal Gwizdala]

Keenan Newton wrote:

My experiences are that from a performnace stance they are about the
same. However, I thought encrypting the SOAP message was simplier.
not to mention using HTTPS is also transport specific. If you want to
use a different protocol such as TCP. Then you are going to need
another mechanism for encrypting your transmissions. I think
eventually the development community will realize sending SOAP messages
via HTTP does not perform well, and maybe using a simplier protocol
like say TCP would be more efficient. My suggestion is to encrypt the
SOAP package that way your encryption is independent of the transport
mechanism you are sending you SOAP messages on

Hello

Did you consider what is easier for your web service clients - to use
custom message encryption, or to use standard SSL connection? There is
no performance gain in using custom encryption, so why choose it?
When you introduce a nonstandard encryption you put a requirement on
your clients to write and maintanin some specific code - that means
bugs, problems, unknown level of compatibility, no portability...
With HTTPS + SOAP you have everything standard, compatible, easy to set
up and maintain and, well, guaranteed to work. And you don't have to
reinvent the wheel when it comes to, for example, client authentication.
You aren't also limited to HTTP with the HTTPS - SSL supports any
application-level protocol, not only HTTP - it is a transport layer just
as TCP.

Best regards,
Rafal Gwizdala

[Richard L Rosenheim]

Thanks for both replies.

In considering your points (and I didn't think about possibility that some
day something besides HTTP/HTTPS could possibly be utilized), it seems that
staying with basic web service protocol and utilizing HTTPS is probably the
best approach to take today.

Yes, the inefficiency of character-based messages (in comparison to binary
data) does bother me. But, I'm not aware of any standard currently in place
to help out in this matter. Utilizing remoting doesn't seem to be the way
to go, especially with Microsoft says that remoting is on it way out.

Richard Rosenheim
"Rafal Gwizdala" <gw*****@poczta.onet.pl> wrote in message
news:Ou**************@tk2msftngp13.phx.gbl...

Keenan Newton wrote:

My experiences are that from a performnace stance they are about the
same. However, I thought encrypting the SOAP message was simplier.
not to mention using HTTPS is also transport specific. If you want to
use a different protocol such as TCP. Then you are going to need
another mechanism for encrypting your transmissions. I think
eventually the development community will realize sending SOAP messages
via HTTP does not perform well, and maybe using a simplier protocol
like say TCP would be more efficient. My suggestion is to encrypt the
SOAP package that way your encryption is independent of the transport
mechanism you are sending you SOAP messages on

Hello

Did you consider what is easier for your web service clients - to use
custom message encryption, or to use standard SSL connection? There is
no performance gain in using custom encryption, so why choose it?
When you introduce a nonstandard encryption you put a requirement on
your clients to write and maintanin some specific code - that means
bugs, problems, unknown level of compatibility, no portability...
With HTTPS + SOAP you have everything standard, compatible, easy to set
up and maintain and, well, guaranteed to work. And you don't have to
reinvent the wheel when it comes to, for example, client authentication.
You aren't also limited to HTTP with the HTTPS - SSL supports any
application-level protocol, not only HTTP - it is a transport layer just
as TCP.

Best regards,
Rafal Gwizdala

[Keenan Newton]

Ummm well Rafal, I have some concerns with reply. First. WS-Security
is a standard; nothing custom about the specification. Secondly, using
SSL is only good point to point in other words from a client to server.
Using WS-Security the SOAP packet can be encrypted along the entire,
say between queues. I rather have my encryption at the message level,
not the transport level. This way I have better control of the
security and integrity of my data throughout my application

[Richard L Rosenheim]

Keenan,

Just to give food for thought regarding your comments.

In one of the projects I'm working on, support for PocketPCs (and
potentially, possibly even Palms) is a requirement. Currently, PocketPC
does not have support for WS-Security. That means either having to (a) wait
for Microsoft (or someone else) to support WS-Security on the PocketPC, (b)
implement WS-Security myself, or (c) roll my own encryption scheme utilizing
one of the cryptographic algorithm supported by the PocketPC and the Palm.

Waiting isn't a preferred option, and both (b) and (c) would mean a lot of
additional development and testing on our side. And, increase the
complexity for anyone else wishing to utilize the web services. Or, we just
utilize HTTPS/SSL and live with that.

Richard Rosenheim
"Keenan Newton" <ka*********@yahoo.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Ummm well Rafal, I have some concerns with reply. First. WS-Security
is a standard; nothing custom about the specification. Secondly, using
SSL is only good point to point in other words from a client to server.
Using WS-Security the SOAP packet can be encrypted along the entire,
say between queues. I rather have my encryption at the message level,
not the transport level. This way I have better control of the
security and integrity of my data throughout my application

[Keenan Newton]

Well both solutions haev there pros and cons. Again I wouod use SSL as
a last resort as it transport specific. If you got to use SSL then
thats fine. There isn';t a silver bullet out there unfortunately and
you are going to ahve to consider your choices and options. And
sometimes you don't have an option such as in the case of the .Net CF.
Happy coding

[Rafal Gwizdala]

"Keenan Newton" <ka*********@yahoo.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Ummm well Rafal, I have some concerns with reply. First. WS-Security
is a standard; nothing custom about the specification. Secondly, using
SSL is only good point to point in other words from a client to server.
Using WS-Security the SOAP packet can be encrypted along the entire,
say between queues. I rather have my encryption at the message level,
not the transport level. This way I have better control of the
security and integrity of my data throughout my application

Well, WS-Security is a standard, from what I know, but
1. The original question did not mention Ws-Security as an alternative to
HTTPS, I understood it as a custom encryption option vs HTTPS.
2. It is quite a young standard, with unknown level of support among
software vendors

But, If HTTPS was not an option, I would of course turn to WS-Security or
some other secure messaging standard, such as S/MIME. But in case of web
services, when you want just a secure communication layer, SSL is probably
the simplest and most efficient.

Best Regards
Rafal Gwizdala