IIS 7.5 Mercurial setup ignoring maxAllowedContentLength

Question

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 cannot get IIS to accept it! I've tried it a thousand different ways at global, local, and every level. It sticks by its default of 30MB and refuses to let me push changesets that are larger than that. It doesn't even close the connection, it just gets to 30MB and stalls completely. It's not a timeout issue, I've tried pushing from the local machine to its IP address.

What the hell is going on?

<?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

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.

Answer 2

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.