Re: [JBoss-dev] jboss.net email transport

[Jason Essington]

On Thursday, November 14, 2002, at 08:55  AM, Matt Munz wrote:

Jason,

  Well, you've peaked my interest...

This method(with digital signatures/encryption) would be more secure
than the Http(s) transport,

Really?  Any articles on the subject?

Using digital signatures / xml encryption would make the soap message more secure over any transport

http://www.xml.com/pub/a/2001/08/08/xmldsig.html

Here are two from JavaWorld about Securing web services in general.
http://www.javaworld.com/javaworld/jw-08-2002/jw-0823-securexml.html
http://www.javaworld.com/javaworld/jw-10-2002/jw-1011-securexml.html

And two from developerworks on xml encryption in general
http://www-106.ibm.com/developerworks/library/x-encrypt/index.html
http://www-106.ibm.com/developerworks/library/x-encrypt2/index.html

Authentication would be near definite
(rather hard to fake),

Is there something in the mail protocol that facilitates this? I'd love to
see a strong argument for "email is more secure than https"...

Email has really NO good authentication system, so rather than depend on the smtp (or whatever) protocal for security and authentication, we use XML-Signature and XML-Encryption
to secure the SOAP message. This method will add additional security to any transport.
http://www.w3.org/TR/SOAP-dsig/
http://www.w3.org/TR/xmldsig-core/
http://www.w3.org/TR/xmlenc-core/

the server would not be exposed to the big bad
internet,

Hmmm. Email attacks are fairly common. Email is, by definition, a part of
the internet. I'm not sure where you're going with this...

The app server itself would not be exposed, it would still have an indirect connection via email (mail server), but the email transport only handles a very small subset of email types and discards the rest.

and the company's IT guys don't have to set up a VPN to every
outside source that needs to update data in the server.

VPNs are bad ;) What's wrong with the tried and true "poking a hole in the
firewall" technique? What about https?

Some companies are rather picky about what gets poked through their firewall, and in some companies certain departments fear the IT group and would rather not bother them to do such things. This just gives another option that doesn't require the poking of holes in the firewall.

Is the idea that "they have to have email anyway, so let's just tunnel over
that"? Wasn't this same argument used for HTTP tunnelling?

HTTP(S) is nice, and would be completely sufficient if incoming packets were allowed in every environment, but since there are situations where this is not possible there is a need for another method. Since the email transport initiates the transaction (contacts the email server to collect messages) it is capable of if performing in situations where http could not. And yes, since the app server already has it's own email account, this is a ready made path to follow.

I am in no way saying that the http transport is bad, I am just trying to create an option for situations where http is not feasible.

Email has it's inherent shortcomings that the implementation of xml-security would help alleviate.

So really what we have here is two-fold, a security infrastructure that allows soap messages to be digitally signed and possibly encrypted and an additional transport that depends on that infrastructure to allow for the secure transmission and authentication of data.

-jason



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development