[OPENAM-994] If Possible: Provide documentation on how to exclude weak
ciphers for the client Created: 05/Dec/11 Updated: 10/Dec/14 Resolved: 14/Aug/13
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Resolved
OpenAM
documentation
Agents-3.1.0-Xpress
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Environment:
Improvement
awillard
Fixed
AME
Not Specified
Issue Links:
Depends
depends on OPENAM-1151 Provide a configurable mechanism to
t...
Relates
Sprint:
Cases:
Agents-4.0
Priority:
Assignee:
Votes:
Major
Mike2
0
Not Specified
Not Specified
All (within reason)
Closed
Sprint 31, Sprint 32
5260
Description
If it is possible to exclude weak cipher's from being used, please include documentation. For
example, SChannel for use with IIS allows the server to remove certain ciphers. However,
amagent does not respect Schannel. The issue is, the server that the request goes to, allows
weak ciphers (RC4). We need to disallow from the client if possible.
Is this a modification to java security?
Comments
Comment by Mark [ 06/Feb/12 ]
Assigning this one to me as it's a CR for the doc.
Comment by Mark [ 08/Feb/12 ]
Let me ask for clarification on the issue.
Is the problem that communication between the policy agent and OpenAM allows weak ciphers?
Or is the problem that communication between the client and IIS with the agent installed allows weak ciphers?
Comment by awillard [ 08/Feb/12 ]
Between the policy agent and OpenAM.
IIS SChannel has been configured to remove ciphers such as RC4. If I use wireshark I can watch the communica
Browser to IIS does not present the weak ciphers. The intercepted request with the agent dll on the IIS server the
to the server that processes the request to see if it the user is authenticated. From our IIS/w2k3 server posts the b
server in another domain. The server in the other domain allows weak ciphers.
Since the request does not originate as a request to IIS but from the dll that the ISAPI filter uses, it relies on the s
domain. The issue is, we require stronger ciphers but they can not disable the weak ciphers in the other domain b
customers use the service that do not require it.
I see the ssl3.dll in the bin directory for the agent. I was wondering basically, is there a way to enforce the cipher
approved. My understanding (which I have been wrong many times before) is the agent uses java and if so, is the
we can place in the java security file or even an agent config value (may be wishful thinking for a future release)
disallow weak ciphers.
The best solution would be for the server processing the request to not send a list of ciphers that contained the w
they are unable to process that request due to other consumers.
Also slightly off topic, is the agent capable of SHA256?
Comment by awillard [ 08/Feb/12 ]
As you can tell I am more a Microsoft/.Net person, so my understanding of java is lacking.
Could it be as simple as correctly following some directions based around:
security.provider.XX=sun.security.pkcs11.SunPKCS11 /nhin/fipsconfig/pkcs11.cfg
where XX is just a place holder for a number.
Comment by Mark [ 09/Feb/12 ]
Thanks for the clarification.
The current web agents – built by the way not from Java but from C/C++ code – rely on the NSS default ("dome
which probably allows all supported ciphers specified in
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla%2Fsecurity%2Fnss%2Flib%2Fssl%2Fsslproto.h&rev=&cv
The current web agents do not have any configurable mechanism to restrict which ciphers are allowed on the age
Comment by Mark [ 27/Feb/12 ]
This is more of an agent issue than a pure OpenAM issue.
Comment by Mark [ 27/Feb/12 ]
is a new feature request for the web agents to allow the behavior.
Comment by Mark [ 14/Aug/13 ]
For UNIX, Linux, com.forgerock.agents.config.ciphers was already documented along with the fix for A
change also includes the link to the Microsoft article on restricting use of cryptographic algorithms and protocols
already part of the upcoming v4 web agents (though not v3.2 agents).
Comment by Mark [ 14/Aug/13 ]
Mike resolved this one with r6136.
Generated at Tue Feb 09 13:13:19 GMT 2016 using JIRA 6.3.9#6339sha1:46fa26140bf81c66e10e6f784903d4bfb1a521ae.