IIS 7.5 Mercurial setup ignoring maxAllowedContentLength

后端 未结 6 1322
长情又很酷
长情又很酷 2020-12-30 10:31

I\'m trying to setup Mercurial on IIS 7.5. I have a web.config for an application directory that is ignoring the maxAllowedContentLength attribute and I simply

相关标签:
6条回答
  • 2020-12-30 11:08

    This is an incompatibility in the SSL module of Python 2.7.3+.

    Bug documented here on the TortoiseHg site, but it applies to all platforms pushing into IIS over HTTPS.

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

    0 讨论(0)
  • 2020-12-30 11:22

    I found a few ways of dealing with this issue:

    To fix this server-side in IIS, download and install https://www.nartac.com/Products/IISCrypto/Default.aspx and click the BEAST button, or force SSL3.0 by disabling other protocols.

    If you don't have access to the IIS server, you can fix it by rolling back Python to version 2.7.2 or earlier.

    If you are adventurous, you can modify the mercurial source in sslutil.py, near the top, change the line

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

    to

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

    This will work around the problem and fix the push limit to mercurial behind IIS.

    If you are interested in why Python 2.7.3 broke this, look at http://bugs.python.org/issue13885 for the explanation (it is security-related). If you want to modify Python itself, in Modules/_ssl.c change the line

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

    back to how it was prior to 2.7.3:

    SSL_CTX_set_options(self->ctx, SSL_OP_ALL);
    

    Compile and reinstall python, etc. This adds more SSL compatibility at the expense of potential security risks, if I understand the OpenSSL docs correctly.

    0 讨论(0)
  • 2020-12-30 11:26

    I have the same setup running, and I needed to add the maxAllowedContentLength attribute today.
    I just inserted it at the bottom of my existing web.config, and it worked at once without problems (with a >100MB commit).

    My complete web.config looks like this now:

    <?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>
    
    0 讨论(0)
  • 2020-12-30 11:28

    As explained in this rant, IIS 7.5 introduces a default setting for maxAllowedContentLength in Machine.config, which will apparently take precedence over whatever you specify in any Web.config.

    To fix this, open IIS Manager, click the server node, choose Configuration Editor, and expand system.webServer/security/requestFiltering and then change requestLimits/maxAllowedContentLength (which happens to default to 30000000 bytes). Remember to click Apply afterwards.

    0 讨论(0)
  • 2020-12-30 11:30

    Like others, the accepted answer didn't work for me.

    The reason the upload fails appears to have to do with an incompatibility in the cipher suite that is negotiated between Mercurial and IIS - specifically, with IIS' default settings, the choice of a CBC-based cipher suite.

    Mercurial version 2.9.1 (the one I've tested) sends this cipher suite order to the server. The suites supported by Windows Server 2008 R2 (and IIS 7.5) with an RSA certificate are bold here:

    • 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

    Only two of those aren't CBC - the RC4 based ones. IIS will pick anything coming before those in both its own and Mercurial's priorities.

    The reason IISCrypto 1.3 worked to fix the issue seems not to be that it disabled SSL 2 (although that's still a good idea), but because it moved RC4 above the CBC cipher suites, due to the BEAST attack. In 1.4, RC4 was moved down again, due to newly found vulnerabilities.

    So... The best compromise seems to be to move IIS' priority for RC4_128_SHA up above AES_256_SHA. Note that the merits of AES 256 over AES 128 in terms of security are widely debated.

    Security-wise, this still prioritizes all the ECDHE CBC ciphers, which Mercurial doesn't support at the moment, but all modern browsers do. IE running on Windows XP as well as Android 2.3 will be using RC4 due to this change - the rest are covered. While RC4 is broken, an attack on it isn't trivial. For my purposes, I think I'll survive. Any user of this method will have to make up their own mind as to whether they'll risk it. :-)

    It's still a compromise, and I'm not at all happy about it, but at least I found a workable (and working) compromise. Now if only there was a way to pick cipher suite order on a per-website basis rather than globally on the server...

    Thanks to @Sahil for pointing me in the direction of this.

    0 讨论(0)
  • 2020-12-30 11:35

    In My case I had to make more changes in the IISCrypto software referenced above.

    I have IIS 7.5 and IISCrypto version 1.4 (latest at time of writing)

    Changing to "Best" or "PCI" profile did not work for me so I did following.

    • Changed the profile back to Best option.
    • Look for the bottom left corner box named SSL Cipher Suite Order.
    • Disable/Uncheck all CBC-based ciphers
    • Restart your computer/Server

    I found a solution from this thread and an answer from Zach Mason worked for me as described above.

    Hope this helps someone.

    0 讨论(0)
提交回复
热议问题