Re: Settings when SSL terminates on the front-end
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeff, On 6/24/15 11:39 AM, Jeffrey Janner wrote: -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Tuesday, June 23, 2015 3:18 PM To: Tomcat Users List Subject: Re: Settings when SSL terminates on the front-end On 17/06/2015 19:08, Jeffrey Janner wrote: I've been deploying letting Tomcat do it all when it came to connectors and SSL, with the app forcing everything to SSL in the security-constraints section. Now I'm setting up a haproxy front- end that will both terminate the SSL and take care of the redirect from HTTP to HTTPS for me and tomcat only running a standard HTTP port on 8080. So my question is, Is it still important for the app to know that it operating secure, and if so, what settings are a must? Yes it is extremely important. You need secure=true for everything received over HTTPS and secure=false for everything received over HTTP. It is simpler in your case since Tomcat only ever sees traffic that has been received over HTTPS. There are several ways to ensure secure=true In your case, setting on the connector is the simplest and best option. If proxying over AJP, the AJP connector takes care of it. The RemoteIP[Valve|Filter] or the SSLValve can handle this if proxying over HTTP. There are several reasons it is important (the first reason is the big one): 1. cookies created over secure connections will have the secure flag set which will ensure that browsers never send the cookie over HTTP. I once watched a customer go very white while I was explaining this when they realised that their banking app was sending authentication cookies over HTTP connections. 2. The user data constraint in web.xml will only be satisfied if secure=true HTH, Mark Thanks for the confirmation Mark. That is what I thought I'd gleaned from previous posts. I will be sure to mark the http connection secure=true in my Tomcat instances. I gather from #2 above, that having the secure setting on the http port, it won't really matter if the security-constraints exists in the web.xml or not, because Tomcat will assume it is already secure. Ergo, I don't have to get the developers to remove it. Tomcat will assume that it is secure, but you should definitely leave it in web.xml in case the deployment changes. You always want the application to protect itself. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVitHpAAoJEBzwKT+lPKRYgZYQAJwGeIWkxjzEFlKeTV4WjF8i eujTfhQv4z2YPvchW8w/evykk/7jb2NGfGvJEHQ1EGm/FcSEs3wEX1/BT5CCjQ1U bVWoBrL9VcDZ4TnYVH+NvYvEa+r4oOB7gO57FjooS9vtbIQkt/0F7F1cfyZwBwmB UMMPy4K1l3+sFQvjo19xND16hx5Y21I5ANYCgNmIygMi5O0hit9qE/hlwUUlQxXq 1LMjcNkC3Ls7SvIg5mUIEIMMTovNUJpaWT86nPrcO1AX5IkXhUXWvlhyqncti1M5 dSg3CzleMRM1PYx4jGsMt3bri8MVMYknc99WpMFCTVDletusdJQvAqyaB4WKIrdi /vX1SldamSVhwBtqT6xooEIagwOotG5GjUokd4UTOmHa56BPmER+L1VZGNjB4HzV pA5cyp5Ez7LQ381I94klklo2B99o/c4Gadu56YviS2xNcBpZA+s+GshwQeaKuQOJ LbeyZWpXnb2Bvq2whr7cXNUVEr2j5eKvYo0eLMLz2LdJmkxfjWg808NqOZ1FpxW9 7ysh7ryuhydhO83MPNJkz29ObbueQ53UUbPLPo6Gx2ou4v2M4KVV9KNOltdHbVyG gaFXKxyBExMDRdYNOG2+v+9S5dCBhUBQr6sQtSFGLdIHfTb8ni68wRWhtvuLX2ep 0W8YmmsZvn62TkVz6F14 =yD+Y -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Settings when SSL terminates on the front-end
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Tuesday, June 23, 2015 3:18 PM To: Tomcat Users List Subject: Re: Settings when SSL terminates on the front-end On 17/06/2015 19:08, Jeffrey Janner wrote: I've been deploying letting Tomcat do it all when it came to connectors and SSL, with the app forcing everything to SSL in the security-constraints section. Now I'm setting up a haproxy front- end that will both terminate the SSL and take care of the redirect from HTTP to HTTPS for me and tomcat only running a standard HTTP port on 8080. So my question is, Is it still important for the app to know that it operating secure, and if so, what settings are a must? Yes it is extremely important. You need secure=true for everything received over HTTPS and secure=false for everything received over HTTP. It is simpler in your case since Tomcat only ever sees traffic that has been received over HTTPS. There are several ways to ensure secure=true In your case, setting on the connector is the simplest and best option. If proxying over AJP, the AJP connector takes care of it. The RemoteIP[Valve|Filter] or the SSLValve can handle this if proxying over HTTP. There are several reasons it is important (the first reason is the big one): 1. cookies created over secure connections will have the secure flag set which will ensure that browsers never send the cookie over HTTP. I once watched a customer go very white while I was explaining this when they realised that their banking app was sending authentication cookies over HTTP connections. 2. The user data constraint in web.xml will only be satisfied if secure=true HTH, Mark Thanks for the confirmation Mark. That is what I thought I'd gleaned from previous posts. I will be sure to mark the http connection secure=true in my Tomcat instances. I gather from #2 above, that having the secure setting on the http port, it won't really matter if the security-constraints exists in the web.xml or not, because Tomcat will assume it is already secure. Ergo, I don't have to get the developers to remove it. That is fine with me. Thanks again. Jeff - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Settings when SSL terminates on the front-end
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thursday, June 18, 2015 8:59 AM
To: Tomcat Users List
Subject: Re: Settings when SSL terminates on the front-end
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jeffrey,
On 6/17/15 2:08 PM, Jeffrey Janner wrote:
I’ve been deploying letting Tomcat do it all when it came to
connectors and SSL, with the app forcing everything to SSL in the
security-constraints section. Now I’m setting up a haproxy
front-end that will both terminate the SSL and take care of the
redirect from HTTP to HTTPS for me and tomcat only running a
standard HTTP port on 8080.
So my question is, Is it still important for the app to know that
it operating “secure”, and if so, what settings are a must?
I would say that Tomcat knowing that it's in secure mode is
important. If for no other reason than the URLs your webapp generates
ought to be sensitive to the protocol being used.
Here is the old setup:
SERVER.XML:
Service name=Catalina
Connector address=${IP_ADDRESS} port=80
maxHttpHeaderSize=8192
maxThreads=50 enableLookups=false redirectPort=443
acceptCount=100
connectionTimeout=2 disableUploadTimeout=true
compression=on
compressableMimeType=text/html,text/xml,text/plain,text/css,text/csv,
text/javascript,text/rtf,text/richtext
/
Connector address=${IP_ADDRESS} port=443
maxHttpHeaderSize=8192
maxThreads=150 enableLookups=false acceptCount=100
connectionTimeout=2 disableUploadTimeout=true
compression=on
compressableMimeType=text/html,text/xml,text/plain,text/css,text/csv,
text/javascript,text/rtf,text/richtext
scheme=https secure=true SSLEnabled=true
If you are still going to connect haproxy - Tomcat using port 443,
then this configuration should still work. Tomcat will be in secure
mode, but you won't have access to the original SSL information, at
least not directly in the usual ways.
Here is the new setup:
SERVER.XML:
Service name=Catalina
Connector port=${tomcatPort} protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 /
You should probably set protocol=https and secure=true. You don't
need redirectPort if this is the connector that handles incoming
connections from haproxy.
Thanks for the commentary Chris.
Just one thing, the proxy -- tomcat connection is expected to be http (8080),
not https.
From paying attention over the years, I think I'm supposed to set secure=true
on the one and only http connector in the current setup.
That is what I am looking for verification.
Jeff
Re: Settings when SSL terminates on the front-end
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jeff,
On 6/23/15 3:24 PM, Jeffrey Janner wrote:
-Original Message- From: Christopher Schultz
[mailto:ch...@christopherschultz.net] Sent: Thursday, June 18,
2015 8:59 AM To: Tomcat Users List Subject: Re: Settings when SSL
terminates on the front-end
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
Jeffrey,
On 6/17/15 2:08 PM, Jeffrey Janner wrote:
I’ve been deploying letting Tomcat do it all when it came to
connectors and SSL, with the app forcing everything to SSL in
the security-constraints section. Now I’m setting up a
haproxy front-end that will both terminate the SSL and take
care of the redirect from HTTP to HTTPS for me and tomcat only
running a standard HTTP port on 8080.
So my question is, Is it still important for the app to know
that it operating “secure”, and if so, what settings are a
must?
I would say that Tomcat knowing that it's in secure mode is
important. If for no other reason than the URLs your webapp
generates ought to be sensitive to the protocol being used.
Here is the old setup:
SERVER.XML:
Service name=Catalina
Connector address=${IP_ADDRESS} port=80
maxHttpHeaderSize=8192
maxThreads=50 enableLookups=false redirectPort=443
acceptCount=100
connectionTimeout=2 disableUploadTimeout=true
compression=on
compressableMimeType=text/html,text/xml,text/plain,text/css,text/cs
v,
text/javascript,text/rtf,text/richtext
/
Connector address=${IP_ADDRESS} port=443
maxHttpHeaderSize=8192
maxThreads=150 enableLookups=false acceptCount=100
connectionTimeout=2 disableUploadTimeout=true
compression=on
compressableMimeType=text/html,text/xml,text/plain,text/css,text/cs
v,
text/javascript,text/rtf,text/richtext
scheme=https secure=true SSLEnabled=true
If you are still going to connect haproxy - Tomcat using port
443, then this configuration should still work. Tomcat will be in
secure mode, but you won't have access to the original SSL
information, at least not directly in the usual ways.
Here is the new setup:
SERVER.XML:
Service name=Catalina
Connector port=${tomcatPort} protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 /
You should probably set protocol=https and secure=true. You
don't need redirectPort if this is the connector that handles
incoming connections from haproxy.
Thanks for the commentary Chris. Just one thing, the proxy --
tomcat connection is expected to be http (8080), not https. From
paying attention over the years, I think I'm supposed to set
secure=true on the one and only http connector in the current
setup. That is what I am looking for verification.
Yup: create one connector for non-secure and another for secure.
Something like this:
client - :80 httpd - :1234 tomcat Connector secure=false
client - :443 httpd - :4321 tomcat Connector secure=true
For the secure=false connector, you'll want to have a redirectPort
configured (likely set to 443), which I believe is the default. It's
not a bad idea to have this port set to indicate that you expect
redirects-to-secure to occur, here.
For the secure=true Connector, you'll also want to set scheme=https
.
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVibTaAAoJEBzwKT+lPKRYjJUQAIkaqSoti6cDezz02mpis+fL
+F5P/ykopZNCSNxM3yc4TmP4gkZYmJylWItHkvKkafgSwjKPcoaaDoSCUD75D9qy
tW8YrsB/JUNDg/ySqPYGE9+jmVTIeJxWrFgSUZqOMu6f3YDj0R6y0VxWBdhIHVxf
lsPANqgYGJBs3dN7kPw7P3QH5wSpcJihiZ9HSHeJzLAP2lnQMV9+0zY9A+I4a0/7
lXW/9v+Le1/Fl7fSWbPn1ESP/fz9Cyv4V2j1TpwMU0H/oKd175QaLSIYbdlZMeKc
gE22Fb43QgmbGondjW3Xra7DqlqbzR0m1Lt0rslFdX7vx5csPUVxzsyoIiFd2WYU
ymYOU4a4L4ivcZ3Qwqus0Fk8xvscJYUkBt8OZqKpQDwYNvUB9tZATywxindc5p3I
B6ZEV9dA8ht3ZoxwfpS/PLZiBuXx7QMA40kcBgMdD+SlIKE7u45e3bwZchDhPZZj
vR2f4adGKiRDGRqTUhZ7uJp8KMNJ6uHLlTRpCRJvfRwpgFxURZScJfx4jKa1BZ3y
73AW7LTGlu5BmxfC2sM9nj8F9s1vjiGcr38i9qKF8rQQ2NWC691fbCI51Sm5O2Ew
wvjt9+h2H98nL7innCbhnIwZ00448RdzPDD7NFF+8SL4/cmGwSp29u2ajlyMvfZP
+STvwS+N8FoM9nyiWECX
=yQ26
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Settings when SSL terminates on the front-end
On 17/06/2015 19:08, Jeffrey Janner wrote:
I’ve been deploying letting Tomcat do it all when it came to connectors
and SSL, with the app forcing everything to SSL in the
security-constraints section. Now I’m setting up a haproxy front-end
that will both terminate the SSL and take care of the redirect from HTTP
to HTTPS for me and tomcat only running a standard HTTP port on 8080.
So my question is, Is it still important for the app to know that it
operating “secure”, and if so, what settings are a must?
Yes it is extremely important.
You need secure=true for everything received over HTTPS and
secure=false for everything received over HTTP.
It is simpler in your case since Tomcat only ever sees traffic that has
been received over HTTPS.
There are several ways to ensure secure=true
In your case, setting on the connector is the simplest and best option.
If proxying over AJP, the AJP connector takes care of it.
The RemoteIP[Valve|Filter] or the SSLValve can handle this if proxying
over HTTP.
There are several reasons it is important (the first reason is the big one):
1. cookies created over secure connections will have the secure flag set
which will ensure that browsers never send the cookie over HTTP. I once
watched a customer go very white while I was explaining this when they
realised that their banking app was sending authentication cookies over
HTTP connections.
2. The user data constraint in web.xml will only be satisfied if
secure=true
HTH,
Mark
Here is the old setup:
SERVER.XML:
Service name=Catalina
Connector address=${IP_ADDRESS} port=80 maxHttpHeaderSize=8192
maxThreads=50 enableLookups=false redirectPort=443
acceptCount=100
connectionTimeout=2 disableUploadTimeout=true
compression=on
compressableMimeType=text/html,text/xml,text/plain,text/css,text/csv,text/javascript,text/rtf,text/richtext
/
Connector address=${IP_ADDRESS} port=443 maxHttpHeaderSize=8192
maxThreads=150 enableLookups=false acceptCount=100
connectionTimeout=2 disableUploadTimeout=true
compression=on
compressableMimeType=text/html,text/xml,text/plain,text/css,text/csv,text/javascript,text/rtf,text/richtext
scheme=https secure=true SSLEnabled=true
SSLHonorCipherOrder=true
SSLCipherSuite=list-of-ciphers
SSLCertificateFile=path-to-server.crt
SSLCertificateKeyFile=path-to-server.key
SSLCertificateChainFile=path-to-server_chain.crt
SSLPassword=password /
Engine name=Catalina defaultHost=localhost
Host name=localhost appBase= webapps
unpackWARs=true autoDeploy=false deployXML = false
Valve className=org.apache.catalina.valves.AccessLogValve
directory=logs
prefix=localhost_access_log. suffix=.txt
pattern=%h %l %u %t quot;%rquot; %s %b /
/Host
/Engine
/Service
CONTEXT.XML: No tomcat-level parameters specified
WEB.XML: (only the important bits, assume servlets and filters won’t change)
security-constraint
web-resource-collection
web-resource-nameEverything/web-resource-name
url-pattern/*/url-pattern
/web-resource-collection
user-data-constraint
transport-guaranteeCONFIDENTIAL/transport-guarantee
/user-data-constraint
/security-constraint
Here is the new setup:
SERVER.XML:
Service name=Catalina
Connector port=${tomcatPort} protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 /
Engine name=Catalina defaultHost=localhost jvmRoute=”serverX”
Host name=localhost appBase= webapps
unpackWARs=true autoDeploy=false deployXML = false
Valve className=org.apache.catalina.valves.AccessLogValve
directory=logs
prefix=localhost_access_log. suffix=.txt
pattern=%h %l %u %t quot;%rquot; %s %b /
/Host
/Engine
/Service
CONTEXT.XML: no changes
WEB.XML: drop the security-constraints section?
Am I missing something from a security standpoint here?
And yes, I’m aware I need to adjust some parameters in the Connector
that are left out in the second example. I’m just interested in things
like secure-cookie, etc.
Jeffrey Janner
Sr. Network Administrator
jeffrey.jan...@polydyne.com mailto:first.l...@polydyne.com
*PolyDyne Software Inc.*
Main: 512.343.9100
Direct: 512.583.8930
*/ /**/cid:image002.png@01CC0FB7.4FF43CE0/*
*/ /*
*Speed, Intelligence Savings in Sourcing*
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail:
Re: Settings when SSL terminates on the front-end
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jeffrey,
On 6/17/15 2:08 PM, Jeffrey Janner wrote:
I’ve been deploying letting Tomcat do it all when it came to
connectors and SSL, with the app forcing everything to SSL in the
security-constraints section. Now I’m setting up a haproxy
front-end that will both terminate the SSL and take care of the
redirect from HTTP to HTTPS for me and tomcat only running a
standard HTTP port on 8080.
So my question is, Is it still important for the app to know that
it operating “secure”, and if so, what settings are a must?
I would say that Tomcat knowing that it's in secure mode is
important. If for no other reason than the URLs your webapp generates
ought to be sensitive to the protocol being used.
Here is the old setup:
SERVER.XML:
Service name=Catalina
Connector address=${IP_ADDRESS} port=80
maxHttpHeaderSize=8192
maxThreads=50 enableLookups=false redirectPort=443
acceptCount=100
connectionTimeout=2 disableUploadTimeout=true
compression=on
compressableMimeType=text/html,text/xml,text/plain,text/css,text/csv,
text/javascript,text/rtf,text/richtext
/
Connector address=${IP_ADDRESS} port=443
maxHttpHeaderSize=8192
maxThreads=150 enableLookups=false acceptCount=100
connectionTimeout=2 disableUploadTimeout=true
compression=on
compressableMimeType=text/html,text/xml,text/plain,text/css,text/csv,
text/javascript,text/rtf,text/richtext
scheme=https secure=true SSLEnabled=true
If you are still going to connect haproxy - Tomcat using port 443,
then this configuration should still work. Tomcat will be in secure
mode, but you won't have access to the original SSL information, at
least not directly in the usual ways.
Here is the new setup:
SERVER.XML:
Service name=Catalina
Connector port=${tomcatPort} protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 /
You should probably set protocol=https and secure=true. You don't
need redirectPort if this is the connector that handles incoming
connections from haproxy.
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVgs6iAAoJEBzwKT+lPKRYM2sQAKej40Cx4Wfc54ZJaHH7qRaC
c4cgV/fJqh4ylB8LBsmwIUO1N9SSavIiDQLc04816OfKw69Jg3CBh6vK0qyDhN0+
l8guZV51AyHgwRPewZ3n79zwWRFeJ9tjhAKC39DOo2URZcTPpwVcTJL3UN1OuouV
FWYbw9kufe0gZsmonrI8ki2Tj1m+PZ1LcBdsSMFSCGFKVVSPuR41UuoJ+GZCG6WZ
bLUyMQ3k0pPBdQ0CUXYUHHafddHCiVZzY/r1rC05zyVZ+z9X0LL0Q91okbo8TUvh
BrQOM7Qt5qBqJV4P+Bb+CtMEyAj9cIK1OJZpAaWVdlBIddiOXimkEh6JNWBToCdo
k3WjmMWQ4CDDIzBoycGOq8Jax8hR8U3Gbiae9/2nuBRTUtaSqw7ijiO9xqMrZ6gT
MzW0vKzp1+seo7UEejBucWRDu/s2LNoHTc410BTBI4KQlko3mNbrI0eDAwVR8/I8
i2PiCLRGbo2l/uPvsoJ6/fj33BUM1zxwGimIssYVZqW8b3AFsDTktoO437KRfiOw
9crNPP0FYzsE6lMrrdn7V560hVRqxoqfX3cfIqp09fJXEjOdpI/75UREihiOSv9L
CqjbrY2YUtb4Lt/DK7j2En5ZBMTF6iChn8YbulrZYzXwkTM20k2Nj8irM1SfUc/E
Q0TgwYeow6Kf3Geb1yyM
=xBvF
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Settings when SSL terminates on the front-end
I've been deploying letting Tomcat do it all when it came to connectors and
SSL, with the app forcing everything to SSL in the security-constraints
section. Now I'm setting up a haproxy front-end that will both terminate the
SSL and take care of the redirect from HTTP to HTTPS for me and tomcat only
running a standard HTTP port on 8080.
So my question is, Is it still important for the app to know that it operating
secure, and if so, what settings are a must?
Here is the old setup:
SERVER.XML:
Service name=Catalina
Connector address=${IP_ADDRESS} port=80 maxHttpHeaderSize=8192
maxThreads=50 enableLookups=false redirectPort=443
acceptCount=100
connectionTimeout=2 disableUploadTimeout=true
compression=on
compressableMimeType=text/html,text/xml,text/plain,text/css,text/csv,text/javascript,text/rtf,text/richtext
/
Connector address=${IP_ADDRESS} port=443 maxHttpHeaderSize=8192
maxThreads=150 enableLookups=false acceptCount=100
connectionTimeout=2 disableUploadTimeout=true
compression=on
compressableMimeType=text/html,text/xml,text/plain,text/css,text/csv,text/javascript,text/rtf,text/richtext
scheme=https secure=true SSLEnabled=true
SSLHonorCipherOrder=true
SSLCipherSuite=list-of-ciphers
SSLCertificateFile=path-to-server.crt
SSLCertificateKeyFile=path-to-server.key
SSLCertificateChainFile=path-to-server_chain.crt
SSLPassword=password /
Engine name=Catalina defaultHost=localhost
Host name=localhost appBase= webapps
unpackWARs=true autoDeploy=false deployXML = false
Valve className=org.apache.catalina.valves.AccessLogValve
directory=logs
prefix=localhost_access_log. suffix=.txt
pattern=%h %l %u %t quot;%rquot; %s %b /
/Host
/Engine
/Service
CONTEXT.XML: No tomcat-level parameters specified
WEB.XML: (only the important bits, assume servlets and filters won't change)
security-constraint
web-resource-collection
web-resource-nameEverything/web-resource-name
url-pattern/*/url-pattern
/web-resource-collection
user-data-constraint
transport-guaranteeCONFIDENTIAL/transport-guarantee
/user-data-constraint
/security-constraint
Here is the new setup:
SERVER.XML:
Service name=Catalina
Connector port=${tomcatPort} protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 /
Engine name=Catalina defaultHost=localhost jvmRoute=serverX
Host name=localhost appBase= webapps
unpackWARs=true autoDeploy=false deployXML = false
Valve className=org.apache.catalina.valves.AccessLogValve
directory=logs
prefix=localhost_access_log. suffix=.txt
pattern=%h %l %u %t quot;%rquot; %s %b /
/Host
/Engine
/Service
CONTEXT.XML: no changes
WEB.XML: drop the security-constraints section?
Am I missing something from a security standpoint here?
And yes, I'm aware I need to adjust some parameters in the Connector that are
left out in the second example. I'm just interested in things like
secure-cookie, etc.
Jeffrey Janner
Sr. Network Administrator
jeffrey.jan...@polydyne.commailto:first.l...@polydyne.com
PolyDyne Software Inc.
Main: 512.343.9100
Direct: 512.583.8930
[cid:image002.png@01CC0FB7.4FF43CE0]
Speed, Intelligence Savings in Sourcing
