Brian Tol writes:
> Not sure if this is a user or developer question, but I thought I'd
> start here:
>
> Does anybody know if an Apache/Tomcat combination connected through
> ajpv13 meetings VISA's security requirements?
>
> http://usa.visa.com/media/business/cisp8_pd.pdf
>
> In particular, the bottom half of page 12 refers to "Network encryption
> (VPN) may be used betweeen any merchant system and any back-end
> database" and on page 14: "When transmitting data across networks,
> always use encryption techniques..."
>
> If I'm reading this correctly, it sound like traffic between Apache and
> Tomcat need to be encrypted.
>
> I know that ajpv13 can detect SSL requests, but is there any support for
> encrypting traffic between the two systems? Or am I just reading this
> wrong?
>
I don't work for a merchant, and while I've familiar with CISP, I've
not been involved with an audit. However, I'll make a few
observations ...
CISP is a voluntary program directed at high volume merchants that
recommends best practices and provides a format a largely
self-administered audit. "Requirements" may be too strong word to use
in this case. (ie, I doubt you'd loose merchant status over use of
ajp13 in any case). There is a lot of ground for interpretation on
things like this, and the spirit of the recommendation seems more
directed at truly bonehead things like running a merchant site at a
co-location facility and connecting it to your in-house order entry
system via an exposed channel. The use of the term VPN in
requirement 1 implies that tunneling ajp13 traffic over a an encrypted
link or an otherwise "secure" network would be sufficient. If you are a
merchant or working for one, feel free to contact your acquiring bank
or processor. They'd likely be able to tell you what others are doing
and what's generally held to be acceptable. I'd be happy to discuss
some of the security issues offline. It's kind of off topic to
tomcat, so mail me direct.
Having said all that, the security of sensitive data between a web
server and tomcat is a genuine issue. Requiring SSL from the outside
protects against external attacks on the datastream, but since the
decryption happens at the web server, but leaves you open to local
attacks. [Envision the disgruntled sysadm giving himself a pay raise
via snarfing packets]. As far as I can tell, there's no encryption
support in ajp1x nor in warp. [Someone please correct me if I'm
wrong. I'm asserting this opinion based on a fairly quick look at the
code.] Of course, you could avoid the problem completely by either
running tomcat standalone or inside the web server via JNI, but both
are likely to raise other issues on a high volume merchant.
Adding support for encryption to the channel is likely to raise issues
beyond the mere matter of programming. For example, there's key
management. You don't want things to be impossible to start, yet
anyone who can snarf packets on the local lan can likely read any
config file that contains a master key.
--
Drew Sudell [EMAIL PROTECTED] http://www.op.net/~asudell
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
