Short version:
Is there a way to configure (preferably programmatically) the max encryption
strength that will be used by the framework when connecting to a particular
SSL-protected web service?
Long version:
Historically, browsers could only be exported to certain countries if they
supported only 40 and 56 bit encryption; 128 bit was restricted. I believe,
based on my readings thus far, that this refers to the strength of the
symmetric key which is negotiated during the SSL handshake and subsequently
used on all data transferred during the session.
I also understand from my readings that the handshaking/negotiation process
attempts to automatically identify and use the strongest encryption supported
by both parties (and in fact, in older versions of SSL, the possibility of
intercepting and altering the support lists was a very real shortcoming of
the protocol).
The above suggests to me that there must be some means provided by the .NET
framework by which I can have control over the maximum strength which a
client application will report it supports to a web service hosted on a
server. Naturally, whether the server will allow that encryption strength is
left to the server configuration.
Unfortunately, I can find no documentation or other material about this
subject. Is there a way to control the max supported encryption strength
that the framework reports to the server? I am specifically speaking about
using the 2.0 framework and using a class deriving from
HttpWebClientProtocol. If there is another approach that would more easily
allow this capability, I'm all ears.
It might be useful to note that I am using client authentication; therefore
a client certificate is also involved. Is it possible that I am incorrect in
my assumptions that this would be controlled by the framework, and that it is
instead determined by content of the certificates? The certificates have
their own strength, but as I understand that is separately used by only the
private-key negotiation process.