Vraag HTTP-statuscode om een ​​slechte of ontbrekende host-header te signaleren


Is er een HTTP-statuscode die geschikt is om te gebruiken voor clients die een slechte hostnaam (of helemaal geen) verzenden via SNI of de HTTP Host-header?

Een oudere vraag adres hoe en waarom dergelijke verzoeken in de eerste plaats gebeuren, evenals hoe u technisch kunt omgaan met hen in Apache. Het heeft echter geen betrekking op de keuze van de statuscode voor het antwoord.

In het verleden heb ik een HTTP-proxy geïmplementeerd die statuscode 502 en een html-pagina zou verzenden om uit te leggen waarom het foutbericht werd geproduceerd. Mijn reden voor het gebruik van 502 was een verwachting dat ik het voornamelijk zou zien vanwege verkeerde configuraties, wat betekende dat de proxy geen geschikte backend kon vinden. In werkelijkheid bleek het veel frequenter te zijn om eenvoudigweg volledig valse hostnamen te zien.

Is er een andere statuscode die meer geschikt is en duidelijk aan de cliënt signaleert dat de server op dit IP-adres de waarde niet herkent die via SNI en / of de Host-header wordt verzonden?


6
2018-01-27 19:29


oorsprong


Waarom geef je specifiek om SNI-matching? SNI komt ten goede aan de klant en alleen aan de klant. Klant vraagt ​​om het certificaat dat bestaat, maar het verifieert een niet-overeenkomende domeinnaam? Zo? Zeker geen schade voor de server. Geef de klanten gewoon de mogelijkheid om die rare manier te authenticeren; misschien vinden ze het leuk om de inhoud van google.com geverifieerd te krijgen door het certificaat van facebook.com. Wie weet. Alleen de host-header is een echte beveiligingsprobleem in deze vraag. - kubanczyk
@kubanczyk Ik heb een proxy die SNI gebruikt om de juiste server te vinden die de TLS-verbinding zal beëindigen. Zonder een correcte hostnaam in SNI van de client kan de proxy nergens de TLS-verbinding beëindigen. Tot nu toe zou het dergelijke TCP-verbindingen gewoon sluiten zonder iets te verzenden. Maar door Michael's te gebruiken antwoord, Ik zou in plaats daarvan die TLS-verbindingen kunnen beëindigen op een host die antwoordt met een vast 7 byte TLS-bericht {0x15, 0x03, 0x03, 0x00, 0x02, 0x02, 0x70}. - kasperd
Dit is het doel van de 'Host'-header, niet het bedoelde gebruik van SNI. Als u naar SNI kijkt, maar de kop 'Host' negeert, bent u niet RFC-compatibel. Als u SNI nodig hebt, onderbreekt u de compatibiliteit met eerdere clients. SNI geeft aan dat de klant een specifieke wil certificaat, geen specifiek website. - kubanczyk
@kubanczyk De Host-header wordt te laat verzonden en is gecodeerd, daarom is SNI in de eerste plaats geïntroduceerd. Elke cliënt die te oud is om SNI te ondersteunen zal waarschijnlijk om vele andere redenen op het internet nutteloos worden. Bovendien heb ik geen clients nodig om SNI te hebben, alleen clients die IPv4 gebruiken, hebben SNI nodig. Clients kunnen verbinding maken via IPv6 en alles werkt prima zonder SNI. - kasperd


antwoorden:


RFC 6066 specificeert of beveelt zelfs geen bepaalde HTTP-fout aan in het geval dat de hostnaam verzonden via SNI niet overeenkomt met de HTTP-host-header. Het doet raad aan dat de server de TLS-handshake afbreekt als de SNI-hostnaam niet een service is. Van sectie 3:

Als de server de ClientHello-extensie heeft begrepen maar      herkent de servernaam niet, de server MOET een van de twee nemen      acties: stop de handdruk door een fataal niveau te verzenden      niet-herkende naam (112) waarschuwing of gaat door met de handdruk.

Aangezien een dergelijk ongeldig verzoek voorbij de TLS-handshake kan komen en in HTTP moet worden geweigerd, is een HTTP-reactiecode nodig. Van al die er zijn, past er maar één echt in de situatie:

6.5.1. 400 slecht verzoek

De 400 (Bad Request) statuscode geeft aan dat de server dit niet kan of      zal het verzoek niet verwerken vanwege iets dat wordt waargenomen      een clientfout (bijvoorbeeld ongeldige request-syntaxis, ongeldig verzoek      bericht framing, of misleidende aanvraag routing).

Dit is in feite de reactie die RFC 7230 aangeeft. Van sectie 5.4 beschrijving van de Host-header:

Een server MOET antwoorden met een 400 (Bad Request) statuscode voor een      HTTP / 1.1-verzoekbericht zonder een veld voor een Host-header en voor elke      verzoekbericht dat meer dan één veld voor de hostheader bevat of een      Host-headerveld met een ongeldige veldwaarde.

Ik zal het sterk aanbevelen tegen hiervoor 502 gebruiken. De semantiek geeft aan dat er iets mis is met de server kant en dat het verzoek zou slagen als het later zou worden geprobeerd.


12
2018-01-27 21:38



unrecognized_name moet triviaal zijn voor mij om te implementeren en een eenduidige verbetering in vergelijking met hoe ik dat scenario momenteel behandel. Wat betreft de HTTP-code die mijn proxy niet noodzakelijk weet of het probleem aan de client- of serverzijde van de proxy ligt, kunnen zelfs verkeerd geconfigureerde DNS-records zijn. Dus je antwoord klinkt goed in het algemeen, maar ik zal dat gedeelte wat nauwkeuriger evalueren voordat ik het toepas op mijn specifieke use-case. - kasperd
Ik denk dat de grootste afhaal hier is dat het voor de klant duidelijk moet zijn dat het probleem bij de cliënt aanwezig is. niet-herkende naam en 400 doen dit. - Michael Hampton♦
Mijn zorg over het gebruik van statuscode 400 is dat het probleem niet noodzakelijkerwijs bij de klant ligt. Het probleem kan te wijten zijn aan niet-geconfigureerde DNS-records. Ook code 400 communiceert niet ondubbelzinnig met de cliënt dat de Host-header is wat de server niet bevalt. Ik heb geïmplementeerd unrecognized_name zoals gesuggereerd (ik had een oud stukje code dat rondliep, dat had maar een kleine verandering nodig om precies dat te doen). En in Chromium wordt het min of meer identiek behandeld als een netwerkconnectiviteitsprobleem, maar in ieder geval zegt de foutmelding ERR_SSL_UNRECOGNIZED_NAME_ALERT. - kasperd
Je hebt altijd de mogelijkheid om het probleem meer specifiek in het antwoordorgaan te beschrijven. HTTP-foutcodes zijn niet gedetailleerd genoeg voor wat u wilt. - Michael Hampton♦
Ik stuurde al die tijd zo'n beschrijving in het antwoordorgaan, hoewel alleen voor HTTP. Het lijkt erop dat er niets meer korrelig is in de huidige standaard dan 400. Ik kan het niet aan de hand van de bewoording zeggen of ongeldige veldwaarde  wordt verondersteld om alles wat syntactisch incorrect is te bedekken of dat het ook verondersteld wordt om perfect geldige DNS-namen te bedekken die toevallig niet geconfigureerd zijn op de server. - kasperd