Depanarea problemelor de comunicare TLS / SSL la efectuarea unei cereri web HTTP in ASP.NET Partea 1

Aceasta este prima parte a unei serii de articole despre depanarea problemelor de comunicatii TLS / SSL atunci cand efectuati interogari Http Web Request sau WCF din aplicatiile dvs. ASP.NET (sau orice aplicatie web, cum ar fi un API web sau WCF) la punctele finale SSL.

Iata un fragment de cod simplu care efectueaza un apel Http catre un punct final. Observati ca solicitarea se face catre un punct final SSL peste HTTPS:

protected void Page_Load (expeditor obiect, EventArgs e) {WebRequest wreq = WebRequest.Create (“https://iis85.buggybits.com/”); WebResponse wres = wreq.GetResponse (); Flux str = wres.GetResponseStream (); StreamReader strr = nou StreamReader (str); sir realresp = strr.ReadToEnd (); Response.Write (realresp); strr.Close (); wres.Close (); }

Dupa cum se vede in fragmentul de cod de mai sus, aplicatia ASP.NET actioneaza ca un client si efectueaza un apel HTTP catre https://iis85.buggybits.com/. Sa presupunem ca aplicatia tinta ruleaza pe alt server.

Cand rulam aplicatia, primim urmatorul mesaj de eroare:

Conexiunea de baza a fost inchisa: nu s-a putut stabili o relatie de incredere pentru canalul securizat SSL / TLS.

Daca ne uitam la detaliile mesajului de eroare (de exemplu: prin dezactivarea erorilor personalizate), vedem ca primim urmatoarele detalii:

Eroare server in aplicatia „/”.

————————————————– ——————————

O conexiune existenta a fost inchisa cu forta de catre gazda de la distanta

Descriere: A avut loc o exceptie nesolutionata in timpul executarii cererea web curenta. Va rugam sa consultati urmarirea stivei pentru mai multe informatii despre eroare si de unde a aparut in cod.

…

[SocketException (0x2746): O conexiune existenta a fost inchisa fortat de gazda la distanta]

System.Net.Sockets.Socket.Receive (Byte [] buffer, Int32 offset, Int32 size, SocketFlags socketFlags) +139

System.Net. Sockets.NetworkStream.Read (Byte [] buffer, Int32 offset, Int32 size) +146

…

[IOException: Imposibil de citit date din conexiunea de transport: O conexiune existenta a fost inchisa fortat de gazda de la distanta.]

System.Net.Sockets.NetworkStream.Read (Buffer [] Byte, offset Int32, dimensiune Int32) +742

Acest mesaj generic de eroare ne spune ca conexiunea TCP a fost inchisa si ca inchiderea nu s-a facut deloc intr-un mod prietenos. Urmarirea stivei in sine nu este foarte utila aici, deoarece vedem doar ca obtinem aceasta exceptie in timp ce primim informatiile de la socket, dar nu exista nicio idee despre ceea ce primeste aplicatia ASP.NET, deci nu exista nicio idee despre problema.

Amintiti-va ca aplicatia ASP.NET actioneaza ca un client aici si trimite o cerere HTTP catre https://iis85.buggybits.com/ care ruleaza pe un computer la distanta. Pentru a ajunge la site-ul de la distanta, serverul pe care ruleaza aplicatia noastra initiaza o conexiune TCP la serverul de la distanta. Deschiderea conexiunii necesita o strangere de mana in trei directii si apoi, deoarece aceasta conexiune ar trebui sa fie deschisa prin SSL, ar trebui sa aiba loc o strangere de mana SSL.

Este posibil ca strangerea de mana TCP sau strangerea de mana SSL sa nu reuseasca. Din anumite motive, certificatul ar putea fi invalid sau strangerea de mana SSL subiacenta ar putea esua.

Pentru a analiza strangerea de mana putem obtine o urma de retea si o putem analiza, dar in unele scenarii este foarte util sa rulati mai intai un „test de browser” :

Regula generala este ca aplicatia ASP.NET (care este clientul nostru in acest scenariu) ar trebui sa poata comunica cu serverul de la distanta fara a primi o eroare de certificat. Spre deosebire de „clientii umani”, un client ASP.NET nu poate spune „OK, inteleg ca certificatul nu este valid pentru solicitarea mea, dar imi asum riscul si voi continua pe site”, deci daca detecteaza o problema cu certificatul, atunci va esua (cu exceptia cazului in care spuneti in mod explicit cererii web HTTP sa ignore erorile de certificat, pe care nu le recomand deloc).

Daca deschidem un browser pe masina pe care ruleaza aplicatia ASP.NET si navigam pe adresa URL, vom primi urmatorul mesaj:

Daca faceti clic pe „continuati cu site-ul web” si verificati detaliile certificatului, acesta ne spune clar ca exista o nepotrivire a numelui:

Si daca faceti clic pe „vizualizati certificatul”, veti vedea ca certificatul este un certificat SAN (nume alternativ de server) obtinut pentru www.buggybit.com si intrarile SAN DNS nu contin adresa noastra URL, iis85.buggybits.com:

Deci, certificatul nu este valid. Pentru a remedia aceasta problema, ar trebui sa mergem la masina IIS unde functioneaza iis85.buggybits.com si sa configuram site-ul web cu un certificat corect. Dupa aceea, putem rula din nou testul browserului si de aceasta data navigam cu succes pe https://iis85.buggybits.com/, iar pagina se deschide foarte bine, fara avertisment certificat.

Un „test de browser” este prima actiune de intreprins pentru a testa conectivitatea, dar exista scenarii in care testul poate sa nu fie util sau chiar inselator. Vom vedea motivul pentru acest lucru si un scenariu mai complex de depanare in urmatoarea noastra postare.

Depanare fericita …

–

AMB