Could not create SSL/ TLS secure channel

4,647 views
Skip to first unread message

Carlos Admirador

unread,
Apr 4, 2018, 6:12:27 PM4/4/18
to AltNet-Hispano
Hola grupo!

Uno de los errores que puede aparecer con HttpWebRequest :


               var webRequest = (HttpWebRequest)WebRequest.Create(URL_API);
                webRequest.Method = "POST";
                webRequest.AllowAutoRedirect = true;
                webRequest.Timeout = 20 * 1000;
                webRequest.ContentType = "application/x-www-form-urlencoded";
                //webRequest.Accept = "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8";
                webRequest.Accept = "application/xml";
                webRequest.UserAgent = "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36";
 
 
                //write the data to post request
                //Postdata : a=1&b=2&c=3
                byte[] buffer = Encoding.Default.GetBytes(postData);
                if (buffer != null)
                {
                    webRequest.ContentLength = buffer.Length;
                    webRequest.GetRequestStream().Write(buffer, 0, buffer.Length);
                }
 
                var resultado = "";
 
                using (WebResponse response = webRequest.GetResponse())
                using (Stream stream = response.GetResponseStream())
                using (var reader = new StreamReader(stream))
                {
                    resultado = reader.ReadToEnd();
                }



Es el siguiente, pu ede pasar "aleatoriamente" (en principio):


            //The request was aborted: Could not create SSL/ TLS secure channel ...
            //Error Descarga. Anulada la solicitud: No se puede crear un canal seguro SSL/ TLS.
            //Type: System.Net.WebException
            //StackTrace:    en System.Net.HttpWebRequest.GetRequestStream(TransportContext & context)
            //   en System.Net.HttpWebRequest.GetRequestStream()
 



no están cerrando los streams de respuesta después de leer el resultado obtenido de la llamada http, por lo que en ocasiones es posible que se les queden varias peticiones abiertas en memoria, en función del número de llamadas efectuadas y llamadas concurrentes que se puedan hacer o de como esté implementado su programa.

Por lo visto la clase HttpWebRequest puede retornar este error por varios motivos, no únicamente por motivos de negociación SSL sino por bloqueos de la propia clase, entre ellos este, o la falta de memoria si se llegaran a quedar demasiadas requests abiertas. En tales situaciones de bloqueo, al cabo de unos minutos el programa vuelve a funcionar puesto que se expiran/cierran todas las conexiones o sockets abiertos.


Stream stream = response.GetResponseStream(); StreamReader reader = new StreamReader(stream); var resultado = reader.ReadToEnd();

--Aqui faltaría cerrar correctamente el stream de respuesta response.Close();


Fuentes:

https://support.microsoft.com/es-ve/help/908573/a-post-or-put-request-may-fail-when-you-use-the-httpwebrequest-class-t

https://stackoverflow.com/questions/5653868/what-makes-this-https-webrequest-time-out-even-though-it-works-in-the-browser
The typical reason for timeout errors with HttpWebRequest/HttpWebReponse calls is "not closing the response object/stream", which keep the connections active.
You have to simply close the Stream object or the HttpWebResponse object after reading the contents of the stream. Default connection-limit is 2.


Alguna forma de monitorizaciónd e los errores ? cómo obtener número de conexiones o sokets abierto ?
Gracias de antemano.

Carlos Admirador

unread,
Apr 6, 2018, 4:19:08 PM4/6/18
to AltNet-Hispano
Cómo activar el análisis de la negociación SSL de nuestro lado (cliente) para ver posibles detalles de dicha negociación SSL ?
Alguna herramienta? Microsoft Network Monitor u otra ?

El proveedor comenta:

"Deberíais activar el análisis de la negociación SSL por vuestro lado para ver posibles detalles de dicha negociación SSL, ya que parece ser que la primera
petición de las 8:30 se os ha devuelto correctamente con un status http 200 y a la segunda ya se os ha cortado o bloqueado la negociación SSL por algún motivo.
Como veis os pongo aqui debajo las negociaciones SSL de las 8:30 y las de las 9:00 (la ejec. manual posterior). En la de las 8:30 se finaliza el envio de
requests a la segunda petición, que podria encajar con los valores por defecto de la clase HTTPwebrequest (2 negociaciones SSL simultaneas por defecto)."


En todo caso, cómo utilizar dicha herramienta para loguear el análisis de la negociación SSL programáticamente en C# ?


En http://ssl-checker.online-domain-tools.com/ comprobamos que la URL dl API soporta TLS 1.2, 1.1,....

Gracias de antemano.

Carlos Admirador

unread,
Apr 16, 2018, 4:55:50 PM4/16/18
to AltNet-Hispano

Using System.Net trace to troubleshooting SSL problem 

To fix this problem, we enabled System.Net tracing, below is the configuration file. Please:


-          Insert this config part into your web.config


-          Make sure application pool identity has write permission to the log file.



<system.diagnostics>


                        <sources>


                                    <source name="System.Net" tracemode="includehex" maxdatasize="1024">


                                                <listeners>


                                                            <add name="System.Net"/>


                                                </listeners>


                                    </source>


                                    <source name="System.Net.Sockets">


                                                <listeners>


                                                            <add name="System.Net"/>


                                                </listeners>


                                    </source>


                                    <source name="System.Net.Cache">


                                                <listeners>


                                                            <add name="System.Net"/>


                                                </listeners>


                                    </source>


                        </sources>


                        <switches>


                                    <add name="System.Net" value="Verbose"/>


                                    <add name="System.Net.Sockets" value="Verbose"/>


                                    <add name="System.Net.Cache" value="Verbose"/>


                        </switches>


                        <sharedListeners>


                                    <add name="System.Net"


                                      type="System.Diagnostics.TextWriterTraceListener"


                                      initializeData="d:\temp\network.log"    />


                        </sharedListeners>


                        <trace autoflush="true"/>


</system.diagnostics>









Carlos Admirador

unread,
Apr 16, 2018, 5:20:19 PM4/16/18
to AltNet-Hispano
El único protocolo seguro de los 5 es TLS v1.2, si lo soporta el servidor. (Cómo configurar un servidor IIS para soportar TLS v1.2?)

There are five protocols in the SSL/TLS family: SSL v2, SSL v3, TLS v1.0, TLS v1.1, and TLS v1.2:

https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices

SSL v2 unsecure, SSL v3 is insecure when used with HTTP (the POODLE attack), TLS v1.0, TLS v1.1 obsolete
 

The SSL 3 protocol (1996) is irreparably broken by the Poodle attack published 2014. The IETF have published "SSLv3 MUST NOT be used". Web browsers are ditching it. Mozilla Firefox and Google Chrome have already done so.

Two excellent tools for checking protocol support in browsers are SSL Lab's client test and https://www.howsmyssl.com/ . The latter does not require Javascript, so you can try it from .NET's HttpClient:


"In the future, when TLS 1.2 is compromised or just superceded, having your code stuck to TLS 1.2 will be considered a deficiency. Negotiation to TLS1.2 is enabled in .Net 4.6 by default. If you have the option to upgrade your source to .Net 4.6, I would highly recommend that change over forcing TLS 1.2."



Reply all
Reply to author
Forward
0 new messages