IIS 7.5 Mercurial Setup Ignorieren maxAllowedContentLength

Question

Ich versuche, Mercurial auf IIS 7.5 einzurichten. Ich habe eine web.config für ein Anwendungsverzeichnis, das das maxAllowedContentLength Attribut ignoriert, und ich kann einfach nicht bekommen IIS, es zu akzeptieren! Ich habe es tausend verschiedene Arten auf globaler, lokaler und jeder Ebene versucht. Es hält sich standardmäßig auf 30 MB und lässt mich keine größeren Changesets pushen. Es schließt nicht einmal die Verbindung, es kommt nur auf 30 MB und bleibt komplett stehen. Es ist kein Timeout-Problem, ich habe versucht, vom lokalen Rechner auf seine IP-Adresse zu drücken.

Was zum Teufel ist los?

<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
    <system.webServer> 
     <handlers> 
      <add name="Python" path="*.cgi" verb="*" modules="CgiModule" scriptProcessor="C:\Python27\python.exe -u &quot;%s&quot;" resourceType="Unspecified" requireAccess="Script" /> 
     </handlers> 
     <security> 
      <requestFiltering> 
       <requestLimits maxAllowedContentLength="1073741824" /> 
      </requestFiltering> 
     </security> 
     <rewrite> 
      <rules> 
       <rule name="rewrite to hgwebdir" patternSyntax="Wildcard"> 
        <match url="*" /> 
        <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> 
         <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" /> 
        </conditions> 
        <action type="Rewrite" url="hgweb.cgi/{R:1}" /> 
       </rule> 
      </rules> 
     </rewrite> 
    </system.webServer> 

    <!-- I don't know if this is supposed to work... it doesn't matter where I put the settings. -->   
    <location path="*"> 
     <system.web> 
     <!-- maxRequestLength is in kilobytes (KB) --> 
     <httpRuntime maxRequestLength="1048576" /> <!-- 1GB --> 
     </system.web> 
     <system.webServer> 
     <security> 
      <requestFiltering> 
      <!-- maxAllowedContentLength is in bytes (B) --> 
      <requestLimits maxAllowedContentLength="1073741824"/> <!-- 1GB --> 
      </requestFiltering> 
     </security> 
     </system.webServer> 
    </location> 
</configuration> 

Answer 1

fand ich ein paar Möglichkeiten, sich mit diesem Thema beschäftigen:

diesen Server-Seite in IIS zu beheben, downloaden und installieren Sie https://www.nartac.com/Products/IISCrypto/Default.aspx und klicken Sie auf die TIER-Taste oder Kraft SSL3.0 durch Deaktivieren andere Protokolle.

Wenn Sie keinen Zugriff auf den IIS-Server haben, können Sie ihn beheben, indem Sie Python auf Version 2.7.2 oder früher zurücksetzen.

Wenn Sie abenteuerlich sind, können Sie die Quecksilber-Quelle in sslutil.py, in der Nähe der Spitze ändern, ändern Sie die Zeile

sslsocket = ssl.wrap_socket(sock, keyfile, certfile, 
      cert_reqs=cert_reqs, ca_certs=ca_certs) 

zu

from _ssl import PROTOCOL_SSLv3 
sslsocket = ssl.wrap_socket(sock, keyfile, certfile, 
      cert_reqs=cert_reqs, ca_certs=ca_certs, ssl_version=PROTOCOL_SSLv3) 

Dieses Problem umgehen wird und beheben das Push-Limit für Mercurial hinter IIS.

Wenn Sie daran interessiert sind, warum Python 2.7.3 dies brach, sehen Sie sich http://bugs.python.org/issue13885 für die Erklärung an (es ist sicherheitsrelevant). Wenn Sie Python ändern möchten sich in Module/_ssl.c die Zeile

SSL_CTX_set_options(self->ctx, 
        SSL_OP_ALL & ~SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS); 

zurück, wie es vor 2.7.3 war:

SSL_CTX_set_options(self->ctx, SSL_OP_ALL); 

Compilieren und installieren Python usw. Diese fügt mehr SSL-Kompatibilität auf Kosten möglicher Sicherheitsrisiken hinzu, wenn ich die OpenSSL-Dokumente korrekt verstehe.

Answer 2

Ich habe das gleiche Setup läuft, und ich musste heute das maxAllowedContentLength Attribut hinzufügen.
Ich habe es nur an der Unterseite meiner bestehenden web.config eingefügt, und es funktionierte sofort ohne Probleme (mit einem> 100MB Commit).

Meine kompletten web.config wie folgt aussieht jetzt:

<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
    <system.webServer> 
     <handlers> 
      <add name="Python" path="*.cgi" verb="*" modules="CgiModule" scriptProcessor="C:\Python26\python.exe -u &quot;%s&quot;" resourceType="Unspecified" /> 
     </handlers> 
     <rewrite> 
      <rules> 
       <rule name="rewrite to hgwebdir" patternSyntax="Wildcard"> 
        <match url="*" /> 
        <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> 
         <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" /> 
        </conditions> 
        <action type="Rewrite" url="hgweb.cgi/{R:1}" /> 
       </rule> 
      </rules> 
     </rewrite> 
     <security> 
      <requestFiltering> 
       <requestLimits maxAllowedContentLength="2147482624" /> 
      </requestFiltering> 
     </security> 
    </system.webServer> 
</configuration> 

Answer 3

Dies ist eine Inkompatibilität in der SSL-Modul von Python 2.7.3+.

Bug dokumentiert hier auf der TortoiseHg Website, aber es gilt auch für alle Plattformen in IIS über HTTPS schieben.

https://bitbucket.org/tortoisehg/thg/issue/2593/cant-push-over-30mb-to-iis-via-https

Answer 4

In meinem Fall musste ich mehr Änderungen in der oben genannten IISCrypto-Software vornehmen.

Ich habe IIS 7.5 und IISCrypto Version 1.4 (neueste zum Zeitpunkt des Schreibens)

Wechsel zu „Best“ oder „PCI“ Profil nicht für mich arbeiten, so habe ich folgende.

• Das Profil wurde zurück in die beste Option geändert.
• Suchen Sie nach der unteren linken Ecke mit der Bezeichnung SSL Cipher Suite Order.
• Deaktivieren/Deaktivieren Sie alle CBC-basierte Chiffren
• Ihrem Computer/Server neu starten

ich eine Lösung aus this thread gefunden und eine Antwort von Zach Mason für mich gearbeitet, wie oben beschrieben.

Ich hoffe, das hilft jemandem.

Answer 5

Wie andere auch, die angenommene Antwort funktionierte nicht für mich.

Der Grund für das Fehlschlagen des Uploads scheint eine Inkompatibilität in der Cipher-Suite zu sein, die zwischen Mercurial und IIS ausgehandelt wird - speziell mit den Standardeinstellungen von IIS die Wahl einer CBC-basierten Cipher-Suite.

Mercurial Version 2.9.1 (die ich getestet habe) sendet diese Cipher Suite Reihenfolge an den Server. Die Suiten unterstützt von Windows Server 2008 R2 (und IIS 7.5) mit einem RSA-Zertifikat sind fett hier:

• TLS_DHE_RSA_WITH_AES_256_SHA
• TLS_DHE_DSS_WITH_AES_256_SHA
• TLS_RSA_AES_256_SHA
• SSL_DHE_RSA_WITH_3DES_EDE_SHA
• SSL_DHE_DSS_WITH_3DES_EDE_SHA
• SSL_RSA_WITH_3DES_EDE_SHA
• TLS_DHE_RSA_WITH_AES_128_SHA
• TLS_DHE_DSS_WITH_AES_128_SHA
• TLS_RSA_AES_128_SHA
• SSL_RSA_WITH_RC4_128_SHA
• SSL_RSA_WITH_RC4_128_MD5

Nur zwei von denen sind nicht CBC - die RC4 basiert sind. IIS wird alles auswählen, was vor den eigenen und den Mercurial-Prioritäten steht.

Der Grund IISCrypto 1.3 arbeitete das Problem scheint nicht zu sein, dass es deaktiviert SSL 2 (obwohl das ist immer noch eine gute Idee) zu beheben, sondern weil es RC4 über den CBC Chiffriersätze bewegt, aufgrund des Angriffs BEAST. In 1.4 wurde RC4 wegen neu gefundener Schwachstellen wieder heruntergefahren.

Also ... Der beste Kompromiss scheint zu sein, die Priorität von IIS für RC4_128_SHA höher als AES_256_SHA zu verschieben. Beachten Sie, dass die Vorteile von AES 256 gegenüber AES 128 in Bezug auf Sicherheit weit diskutiert werden.

Sicherheit priorisiert immer noch alle ECDHE CBC-Chiffren, die Mercurial im Moment nicht unterstützt, aber alle modernen Browser tun dies. IE unter Windows XP sowie Android 2.3 wird aufgrund dieser Änderung RC4 verwenden - der Rest ist abgedeckt. Während RC4 ist gebrochen, ein Angriff auf es ist nicht trivial. Für meine Zwecke, ich denke Ich werde überleben. Jeder Benutzer dieser Methode muss sich selbst entscheiden, ob er es riskiert. :-)

Es ist immer noch ein Kompromiss, und ich bin nicht glücklich darüber, aber zumindest habe ich einen bearbeitbar (und Arbeits) Kompromiss. Nun, wenn es nur eine Möglichkeit gäbe, die Reihenfolge der Cipher Suite auf einer Website-Basis und nicht global auf dem Server zu wählen ...

Danke an @Sahil, dass er mich in die Richtung weist.

Answer 6

Wie in this rant, IIS 7.5 eine Standardeinstellung für maxAllowedContentLength in Machine.config einführt, die offenbar Vorrang wird über alles, was Sie in jedem Web.config angeben.

Um dies zu beheben, öffnen Sie den IIS-Manager, klicken Sie auf den Serverknoten, wählen Sie Konfigurationseditor und erweitern Sie system.webServer/security/requestFiltering und ändern Sie dann requestLimits/maxAllowedContentLength (was standardmäßig auf 30000000 Bytes geschieht). Denken Sie daran, danach auf Anwenden zu klicken.