Requiring 128 Bit Encryption when users access web site
We have discovered an issue with our web server in which we are trying to validate that users who do not have 128 bit encrypted browsers are prompted to update their browser to one that is 128 bit compliant. We are doing this via the Netscape iPlanet 4.1 server. From what we are seeing, clients who access via https://www.domainname.com/ are properly redirected as they should if they are less than 128 bit, while users who access https://www.domainname.com/uri/servlet are allowed through without being checked/redirected as they should.
Is anyone aware of any issues that could cause this? I have looked at all possible options on my end and am either missing the glaringly obvious, or there is something else that is going on...
Any feedback would be greatly appreciated.
Is anyone aware of any issues that could cause this? I have looked at all possible options on my end and am either missing the glaringly obvious, or there is something else that is going on...
Any feedback would be greatly appreciated.
ahoffmann
can you please post the relevant part from your obj.conf which handles the 128bit check
ASKER
PathCheck fn="ssl-check" secret-keysize="128" bong-file="/opt/netscape/s
ASKER
bumping points up as this is becoming an urgent issue...
do you have thi in the <Object name="default"> scope ?
not shure but if it is ibn that sscope, you probaly have to define it in each <Object > scope
not shure but if it is ibn that sscope, you probaly have to define it in each <Object > scope
ASKER
ahoffman,
based on what I am seeing, we have the PathCheck defined under the default object. We also have objects for servlet and jsp along with a few others listed in there. Based on what you are saying, I take it this line (PathCheck fn="ssl-check" secret-keysize="128" bong-file="/opt/netscape/s
based on what I am seeing, we have the PathCheck defined under the default object. We also have objects for servlet and jsp along with a few others listed in there. Based on what you are saying, I take it this line (PathCheck fn="ssl-check" secret-keysize="128" bong-file="/opt/netscape/s
ASKER
I tried adding the PathCheck to each of the Object Names defined and was still allowed to access the site using less than 128 bit encryption... I did end up removing the ciphers from the server leaving only the following ciphers enabled:
SSL 2.0 ciphers:
RC4 with 128 bit encryption and MD5 message authentication
RC2 with 128 bit encryption and MD5 message authentication
Triple DES with 168 bit encryption and MD5 message authentication
SSL 3.0 ciphers:
RC4 with 128 bit encryption and Fortezza/SHA message authentication
RC4 with 128 bit encryption and MD5 message authentication
Triple DES with 168 bit encryption and SHA message authentication
(FIPS) Triple DES with 168 bit encryption and SHA message authentication
With doing this, the site now returns an error to the user when using netscape communicator 4.6 - "Netscape and thsi server cannot communicate securely because they have no common encryption algorithm(s)." Optimally, this is not the way that I would like to do it, however, if I am unable to get the PathCheck/bong-file line to work, then we will have to stick with this.
Ahoffman, can you expound on your response in a little more detail please?
SSL 2.0 ciphers:
RC4 with 128 bit encryption and MD5 message authentication
RC2 with 128 bit encryption and MD5 message authentication
Triple DES with 168 bit encryption and MD5 message authentication
SSL 3.0 ciphers:
RC4 with 128 bit encryption and Fortezza/SHA message authentication
RC4 with 128 bit encryption and MD5 message authentication
Triple DES with 168 bit encryption and SHA message authentication
(FIPS) Triple DES with 168 bit encryption and SHA message authentication
With doing this, the site now returns an error to the user when using netscape communicator 4.6 - "Netscape and thsi server cannot communicate securely because they have no common encryption algorithm(s)." Optimally, this is not the way that I would like to do it, however, if I am unable to get the PathCheck/bong-file line to work, then we will have to stick with this.
Ahoffman, can you expound on your response in a little more detail please?
ASKER
also, if this helps, these are the other object defs outside of the default that are in the obj.conf:
<Object name="cgi">
ObjectType fn="force-type" type="magnus-internal/cgi"
Service fn="send-cgi"
</Object>
<Object name="servlet">
ObjectType fn="force-type" type="text/html"
Service fn="NSServletService"
</Object>
<Object name="jsp">
Service fn="NSServletService"
</Object>
<Object name="ServletByExt">
ObjectType fn="force-type" type="magnus-internal/serv
Service type="magnus-internal/serv
</Object>
<Object name="es-internal">
PathCheck fn="check-acl" acl="es-internal"
</Object>
<Object name="cgi">
ObjectType fn="force-type" type="magnus-internal/cgi"
Service fn="send-cgi"
</Object>
<Object name="servlet">
ObjectType fn="force-type" type="text/html"
Service fn="NSServletService"
</Object>
<Object name="jsp">
Service fn="NSServletService"
</Object>
<Object name="ServletByExt">
ObjectType fn="force-type" type="magnus-internal/serv
Service type="magnus-internal/serv
</Object>
<Object name="es-internal">
PathCheck fn="check-acl" acl="es-internal"
</Object>
puuuh, need to guess 'cause I don't have experiance with such a problem.
Checked my Netscape/iPlanet docs, but they are not helpful about ssl-check, unfortunately :-(
I'll try again, please give me a ping here if I don't respond next few days ..
Checked my Netscape/iPlanet docs, but they are not helpful about ssl-check, unfortunately :-(
I'll try again, please give me a ping here if I don't respond next few days ..
no, these object do not matter, they serv your cgi, jsp, etc.
only those for specifying directories and (virtual) locations are of interrest
only those for specifying directories and (virtual) locations are of interrest
ASKER
ahoffmann,
any updates that you can provide to this?
thanks
any updates that you can provide to this?
thanks
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
ozz....
post was not closed out as of yet, but the points were refunded....
thanks
post was not closed out as of yet, but the points were refunded....
thanks