Why is .NET CF 2.0 (HttpWebRequest Class) using 40-bit Encryption over HTTPS?

This post is a continuation of these previous posts:
How do I install a SSL Certificate on a WinCE 5.0 Device? (Apr. 10, 2008)
Packaging _setup.xml (for SSL Cert) into WinCE 5.0 CAB using CabWiz? (Apr.
28, 2008)

Ladies and Gentlemen,
I am investigating how to properly implement SSL Certificates because our
WinCE 5.0 mobile device are apparently using 40-bit encryption when
communicating to our SSL Servers. I'm trying to determine why the encryption
level is not 128-bit. Our IT Department increased the security levels on our
servers to 128-bit and all of a sudden my .NET 2.0 CF apps were unable to
communicate with the web apps until they lowered it back down to 40-bit!!?

I had the IT guys setup a server on our intranet, with our SSL Cert
installed and the security level raised to allow only 128-bit encryption,
just so I can test my mobile application against it. I have converted and
installed our SSL Cert on the mobile device (see previous posts listed
above) and it still fails to communicate with the newly configured server.
If they lower the security level down to 40-bit my application works
perfectly.

According to the article listed here
(http://msdn.microsoft.com/en-us/library/bb738067.aspx):
"The .NET Compact Framework has built-in support for SSL. This support
includes the use of sockets, Web (HTTP) requests, and XML Web service calls.
You simply have to change the URL to begin with https:// instead of http://
to enable SSL."
It also goes on to state "Even if a certificate is not installed on the
device, it is still possible to use SSL with any Web server that has a
certificate installed."

Even though this article is referring to Windows Mobile 6 I have seen posts
elsewhere indicating the same for WinCE 5.0 using .NET CF 2.0. I have
followed all the "rules" for implementing HTTPS communications using the
HttpWebRequest class by creating a CheckValidationResult method, in a
LocalCertificatePolicy class, which always returns true and I specify
"https://"; in the URL when creating the HttpWebRequest object. Despite all
of these efforts I cannot get my application to communicate at 128-bit
encryption using these Symbol MC3090 WinCE 5.0 mobile devices!!!

What am I doing wrong??? Are there any properties of the created
HttpWebRequest object that I have to set? I had run into a bug in the
distant past whereby specifying the httpRequest.ContentLength when
performing a "POST" caused problems when using HTTPS in .NET CF 1.0 but I
removed that restriction when I moved the project to .NET CF 2.0. Could that
still be an issue in 2.0? However, come to think of it, all I'm doing is a
"GET" and I still have problems...

The following shows how I create the HttpWebRequest object and the
properties I set:
hwrRequest = CType(WebRequest.Create("https://subdomain.domain.com";),
HttpWebRequest)
With hwrRequest
.AllowAutoRedirect = False 'Do not allow redirects
.KeepAlive = True 'Keep the connection alive
.Timeout = 120000 'Default milliseconds to wait
.AllowWriteStreamBuffering = True 'Allow data to be buffered
End With
ServicePointManager.CertificatePolicy = New LocalCertificatePolicy

For the "GET" operation I also set the "Content-Type" equal to "text/html".
I then start a separate thread which performs:
Dim asncResult As IAsyncResult = hwrRequest.BeginGetResponse(AddressOf
RespCallback, hwrRequest)

After that I simply wait for a response to the request...

I receive "ArgumentOutOfRangeException" within the routine that gets the
response when the code starts to read from the response stream buffer. After
researching this error I found that it can be due to a zero-length buffer in
the response stream, which apparently in the underlying structure of the
HttpWebRequest/HttpWebResponse classes contains a negative value for the
buffer length and this generates the "ArgumentOutOfRangeException".
However!! If I have the IT guys lower the security level to 40-bit
everything works again!!???

In the initial (first) web request, all I'm doing is asking for the contents
of the main webpage on the specified URL. I'm not trying to do anything
fancy; I'm not downloading any resources or streaming anything like sound or
video. I just request the main webpage.

Single question: How do I properly implement 128-bit encryption using .NET
CF 2.0 and the HttpWebRequest/Response classes?

(And yes, I can successfully browse to the URL that I'm specifying in my
application using Internet Explorer on the mobile device, so I know it must
be supporting 128-bit encryption.)

I'm at the end of my rope...
P L E A S E H E L P ! ! !

Thank you,
Greg Hellem


.

Relevant Pages

  • Re: SSL Overhead?
    ... Encryption itself isn't the sole culprit of data expansion. ... behind data expansion is the web service - and not SSL. ... I don't see how your comment on security has any credence. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Secure web authentication system w/o SSL and PKI
    ... Authentication has nothing to do with SSL. ... Why do you want symmetric encryption? ...
    (comp.security.misc)
  • RE: ssh and ids
    ... box is the termination point of the SSL tunnel. ... Subject: ssh and ids ... Your claim is only partially true Peter. ... Encryption remains the bane of network-based intrusion ...
    (Focus-IDS)
  • Re: Why is .NET CF 2.0 (HttpWebRequest Class) using 40-bit Encryption over HTTPS?
    ... EndGetResponsemethod on the HttpWebRequest object. ... encryption, or requires no encryption at all, then my code works perfectly. ... I am investigating how to properly implement SSL Certificates because our ... above) and it still fails to communicate with the newly configured server. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: username and Password sent as clear text strings
    ... encryption of the traffic. ... SSL is used. ... client, it would seem like too much hassle for a low possibility hack. ... This is how all web applications on the planet work today by design. ...
    (Pen-Test)