Why does. Net CF fail to call HTTPS Web Services ?!

Why does. Net CF fail to call HTTPS Web Services ?!

White:

Today, I read the blog of the. NET Framework compact team and found a very useful blog by: andarno,

The original Article address is:

Http://blogs.msdn.com/andrewarnottms/archive/2007/11/19/why-net-compact-framework-fails-to-call-some-https-web-servers.aspx

Next, the younger brother will, according to his own understanding and dictionary interpretationArticleLet's talk about the causes and solutions of this problem (from andarno.

 

Body:

A bug was found in. Net CF 2.0 (SP2 or earlier) and 3.5, which mainly causedProgramWhen an HTTPS service request fails using the httpwebrequest method, a prompt is returned: (for Web Services)

System. net. webexception: unable to read data from the transport connection. ---> system. net. sockets. socketexception: Unknown error (0x0 ).

At system. net. httpwebrequest. fillbuffer (httpwebrequest request, connection, coreresponsedata data)

At system. net. httpwebrequest. Getline (httpwebrequest request, connection, coreresponsedata data)

At system. net. httpwebrequest. parseresponse (httpwebrequest request, connection, Boolean defakeepkeepalive)

At system. net. httpwebrequest. startreceiving (connection)

At system. net. Connection. startreceiving (Object ignored)

At system. Threading. threadpool. workitem. dowork (Object O)

At system. Threading. Timer. Ring ()

 

At system. net. httpwebrequest. finishgetresponse ()

At system. net. httpwebrequest. getresponse ()

//...

At program. Main (string [] ARGs)

 

Although the content and cause of the exception prompt are the same, stack trace information is different when you call the standard httpwebrequest in your program.

 

However, there are many causes for this exception, one of which is that the server sends an empty encrypted data packet to the. netcf client. The following figure shows the encryption process on the https server:

First, the server initializes an unencrypted data packet to be sent to the client through the network, and saves it To the memory buffer.

Step 1:

Unencrypted data

Second, the server calls the encryptmessage method to encrypt the unencrypted data packet at an appropriate location. It adds a header and footer to this packet:

Step 2:

Header

Encrypted data

Footer

The header length may be 5 bytes, so the footer is longer. For this data packet, its length must be greater than the unencrypted data length. In the next step, it will be sent to the receiving end and decrypted using the decryptmessage method.

 

Now, when the server encrypts a zero-length stream into a data packet and sends it to the client, the SSL stack of. netcf becomes a problem.

Step 1:		0 byte of unencrypted data
Step 2:	Header	Non-0 bytes of encrypted data	Footer

 

Obviously, the data packet length has changed before and after encryption. When this packet is sent to the. netcf client, the current version (Press: 2.0/3.5). Netcf will decrypt the data packet and return a zero-length data stream to the caller (In my opinion, the caller mentioned below should also be the server.).

In general, for the read method in a network (As mentioned above, the server sends a data to the client, and the client returns a result to the server according to certain rules, the server uses the read method for receiving). It is executed only after the data is received. Otherwise, it is blocked. If the received data is a zero-length data stream, it means that the socket connection has been closed.

Because netcf returns an empty data stream (According to the translator: Why do we need to return like this? We mentioned the bug at the beginning of this article. It seems that it is difficult for us to solve it fundamentally.), The caller will mistake the returned empty data stream as a socket connection disconnection signal, so it will terminate this connection with the client.

In fact, this is the whole process of receiving a response from a null packet when the. netcf program calls the Web service through SSL. The result is that the connection fails and an exception message is thrown before the server responds.

So what causes the server to send such an empty encrypted data packet? Technically speaking, it is because these NULL packets are allowed for transmission (although they are meaningless) That all depends on how your server is configured, to ensure that such a situation does not occur or rarely occurs.

However, unfortunately, there is no way for. netcf to ignore such empty data packets (In my opinion, netcf refers to the client program.), So only the following work und is used, from simple to complex:

1. Do not use SSL for requests (because requests and responses are in plain text, security risks may occur)

2. reconfigure the existing server program to avoid generating empty encrypted data packets.

3. Build a new web server that will forward your device's requests on a separate connection to the ultimate target server and forward the responses back to the device. this wocould work for web sites and Web services. but this new front-end server (which serves something of the role of a proxy server) wowould have to be configuredNotGenerate these empty encryption packets.

4,[Addded 1/2/08]Build a device-side web proxy that callinto the sspi functions itself (native wowould probably be easier than managed for this ). then have your managed app call into the proxy. this proxy wocould be responsible for consuming the empty packets and re-encrypting everything (if necessary to secure IPC) for the app on the same device without any empty SSL packets.

5. Wait until a future version of netcf that fixes this bug.

6. Write your own HTTPS client using native code or P/invoke 'ING from netcf (difficult to get right ).

Translation complete!

Haha, I didn't expect it. Let's take a look at Jack later. I feel that English is more direct! I feel that it is helpful to read these blogs from time to time. Here I would like to thank andarno for their contributions. Although this is a long time ago, I hope this article will be useful to you. I will continue to work hard.

 

I haven't read e for a long time. In fact, I only read and understand this article for more than 10 minutes, but it took more than 30 minutes to translate it. In many cases, the English language is very straightforward and clear, it is often in Chinese, but it is stuck in Yin. I try to blame myself for my insufficient Chinese vocabulary and professional knowledge. Hey hey ......