Exposing to the outside world...

WayneBeck · ‎Feb 18, 2014

We have just upgraded to 10.1 and would like to get input from other companies on how they deal with giving people access to projectlink. Our 9.1 system was only a https so exposing this was easy. But I would like to leave the internal address a http and only use https for the outside world. My network guy setup a netscaller to handle the https traffic but when it gets routed to the windchill server it bounces to http,which we are not allowing access to the outside world. I would like the load of the encryption to be placed on the netscaller and not my windchill system. Any input would be great.

AL_ANDERSON · ‎Feb 18, 2014

We use https for internal and external without any negative side effects
that we can identify. This allows our internal users to surcurely log in
from home or overseas without needing to use VPN - a huge benefit over
http even for internal users.

Al

[solutions] - Exposing to the outside world...

Wayne Beck

ptc-478260 · ‎Feb 18, 2014

<crypto rant=" of=" the=" day=">

Even on an internal LAN using basic authentication over HTTP is inadvisable; particularly if authentication is integrated with AD.

There is normally considerable effort put into protecting logon credentials on a network (Kerberos anyone?) and systems that integrate with single sign on (e.g. AD) and then use basic authentication without employing protection such as TLS or IPSEC introduce a serious vulnerability.

If you can sniff that password on the client or server, anyone in between can sniff it too. You might say 'I have a switched network', but it's easy to spoof your servers mac, poison your arp cache and turn that switch into an expensive hub, or maybe just nab the creds for that switch and setup a monitor port (your IT guys remembered to harden those switches right?! If they did I bet they might get a bit upset about the basic auth on the wire....)

If there is ANY basic auth on your internal LAN; you have a security deficiency. Maybe you design church pews and just don't care, or maybe you design something more interesting and really should care about protecting your authentication traffic, your intellectual property...

Oh and when you enable TLS for HTTP; maybe look into taking that one further step to ensure you are selecting cypher suites that utilize ephemeral Diffie-Helman for forward secrecy... it isn't exactly new and yet sadly under-implemented.

</crypto>

Ian Bagnald, CISSP
Sr. System Support Analyst

patrickchin2000 · ‎Feb 18, 2014

Actually, I wish you can have internally http then externally https with the same URL and hostname. I just wish that flexibility with Windchill. But, because Windchill uses java applets with RMI tunneling for https, it cannot be configured for both http internally and https externally. Then you can more flexible with solutions to either turn it on or off internally or externally. With HTTPS, you now have to worry about performance with encryption and decryption.

Patrick

In Reply to Wayne Beck:

We have just upgraded to 10.1 and would like to get input from other companies on how they deal with giving people access to projectlink. Our 9.1 system was only a https so exposing this was easy. But I would like to leave the internal address a http and only use https for the outside world. My network guy setup a netscaller to handle the https traffic but when it gets routed to the windchill server it bounces to http,which we are not allowing access to the outside world. I would like the load of the encryption to be placed on the netscaller and not my windchill system. Any input would be great.

RajeshBalasunda · ‎Feb 18, 2014

Patrick,

We have a cluster architecture and I set up a slave server in the DMZ zone which will accept https request. The cert will be on Apache and also in the App Director.

All internal users will go through http to the internal slaves.

Also all internal users will go through AD and external through Windchill DS (this is convenient to maintain the external vendors in DS and not add them to the corporate AD)

Not sure if this can be achieved via a monolithic architecture.

Thanks!

Rajesh Balasundaram
IT Site Leader/Windchill System Administrator
Optical Connectivity Solutions Keller Plant

Corning Optical Communications LLC
9275 Denton Highway
Keller, TX 76244

t 817 431 7337
m 817 676 2868
E-mail rajesh.balasundaram@corning.com

ptc-478260 · ‎Feb 18, 2014

If TLS encryption/decryption performance is a real problem buy a hardware application delivery controller and let it do the encryption/decryption; get one that does Layer 7 URL rewrite so the server doesn't need to know that HTTPS is ever being applied, isolate that server on a network segment behind the application delivery controller.

This is not something specific to Windchill; this is how to protect any web application.

Ian Bagnald, CISSP
Sr. System Support Analyst

jessh · ‎Feb 18, 2014

I'd be interested to *know*, but I suspect that a good portion of
purported performance problems in this area are the initial connection
handshake latency/overhead combined with handling of issues with
Internet Explorer and HTTP keep alive.

Older Apache HTTPS configurations have:

BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

which disables HTTP keep alives when HTTPS is used.

Recent PTC Apache HTTPS configurations have

# Adjust the default BrowserMatch to be a little more granular
# in downgrading connection features [PTC]
# All MSIE versions need ssl-unclean-shutdown
BrowserMatch "MSIE" ssl-unclean-shutdown
# MSIE versions 2-5 need additional downgrades
BrowserMatch "MSIE [2-5]" nokeepalive downgrade-1.0 force-response-1.0

There are still issues with HTTP keep alive in the latest Internet
Explorer versions, by the way, but these are not specific to HTTPS and
certainly don't justify disabling keep alive specifically for HTTPS.

--
Jess Holle

patrickchin2000 · ‎Feb 18, 2014

Hi Jess,

You know for sure thatevery time you ask a process or task to stay alive, this basic premise is that you keep open longer because it takes longer to complete as a result you can backlog other process or task which cause contention in your CPU and memory. This is not really best practice but a workaround. Performance is not just if it just crashes or hangs, it is the speed in which you accomplish your task. I do agree with forcing a shutdown of bad frozen process that is actually hung. DoesPTC know when a process is just spinning its wheels to force it to shutdown and not from just stayalive time? That will be a great tool.

The original question is raised about whether http or https.I would like PTC to have both for http internally and https externally. The onlyWC 9.1 PTC current supported solution Iknow is to cluster with a load balancer with method servers and apache configured with http on one slave and https on the other slave with a load balancer deciding which client is internal and external if you need the same hostname url. I don't know if it is the same for WC 10.# but with Windchill similar properties configurations,butit looks so. If you have a proxy, both internal and external has to be https.

There is no reason to have CADWorkers or publishers working in https when they are sitting in the server room. on the same rack or in the same blade chassis.

That's my 2 cents which is worth in Canadian not much.

Hey you got to love that movie "The Lego Movie" where we are just ordinary guys but everything is awesome!

Can you believe I saw that in IMAX 3D.

Patrick

In Reply to Jess Holle:

I'd be interested to *know*, but I suspect that a good portion of
purported performance problems in this area are the initial connection
handshake latency/overhead combined with handling of issues with
Internet Explorer and HTTP keep alive.

Older Apache HTTPS configurations have:

BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

which disables HTTP keep alives when HTTPS is used.

Recent PTC Apache HTTPS configurations have

# Adjust the default BrowserMatch to be a little more granular
# in downgrading connection features [PTC]
# All MSIE versions need ssl-unclean-shutdown
BrowserMatch "MSIE" ssl-unclean-shutdown
# MSIE versions 2-5 need additional downgrades
BrowserMatch "MSIE [2-5]" nokeepalive downgrade-1.0 force-response-1.0

There are still issues with HTTP keep alive in the latest Internet
Explorer versions, by the way, but these are not specific to HTTPS and
certainly don't justify disabling keep alive specifically for HTTPS.

--
Jess Holle

patrickchin2000 · ‎Feb 18, 2014

Thanks Rajesh,

that's exactly what I came up with and discussed with to PTCin the pastwhich I thought was pretty expensive purchasing a load balancer adding additional servers and the complexity of support and maintenance.Sometimes you just don't need that much overhead. In Apache, it is OOTB. But, like I mentioned, it's all Windchillconfiguration on method server properties for java RMI tunneling. I can tell from all the old applets that are still in Windchill that this is not going away anytime soon. You need to spend more money for something that should be OOTB.

Thanks

In Reply to Rajesh Balasundaram:

Patrick,

We have a cluster architecture and I set up a slave server in the DMZ zone which will accept https request. The cert will be on Apache and also in the App Director.

All internal users will go through http to the internal slaves.

Also all internal users will go through AD and external through Windchill DS (this is convenient to maintain the external vendors in DS and not add them to the corporate AD)

Not sure if this can be achieved via a monolithic architecture.

Thanks!

Rajesh Balasundaram
IT Site Leader/Windchill System Administrator
Optical Connectivity Solutions Keller Plant

Corning Optical Communications LLC
9275 Denton Highway
Keller, TX 76244

t 817 431 7337
m 817 676 2868
E-mail rajesh.balasundaram@corning.com

JimTVancouverCa · ‎Apr 22, 2014

Hello Ian,

Just two quick questions about your advice:

Would we *configure* or *compile* our Apache server on Windows?

We will be using an SSL certificate so does this mean the configuration is:

SSLCipherSuite EDH

From http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslciphersuite

Thanks again!

- Jim

In Reply to Ian Bagnald:

Even on an internal LAN using basic authentication over HTTP is inadvisable; particularly if authentication is integrated with AD.

There is normally considerable effort put into protecting logon credentials on a network (Kerberos anyone?) and systems that integrate with single sign on (e.g. AD) and then use basic authentication without employing protection such as TLS or IPSEC introduce a serious vulnerability.

If you can sniff that password on the client or server, anyone in between can sniff it too. You might say 'I have a switched network', but it's easy to spoof your servers mac, poison your arp cache and turn that switch into an expensive hub, or maybe just nab the creds for that switch and setup a monitor port (your IT guys remembered to harden those switches right?! If they did I bet they might get a bit upset about the basic auth on the wire....)

If there is ANY basic auth on your internal LAN; you have a security deficiency. Maybe you design church pews and just don't care, or maybe you design something more interesting and really should care about protecting your authentication traffic, your intellectual property...

Oh and when you enable TLS for HTTP; maybe look into taking that one further step to ensure you are selecting cypher suites that utilize ephemeral Diffie-Helman for forward secrecy... it isn't exactly new and yet sadly under-implemented.

Ian Bagnald, CISSP
Sr. System Support Analyst