Question

我编写了一个Java客户端应用程序，它使用客户端证书通过HTTPS连接到Apache Web服务器，并对服务器执行文件的HTTP PUT。它适用于小文件，但与大文件崩溃。

Apache服务器日志显示以下内容：

...
OpenSSL: Handshake: done
...
Changed client verification type will force renegotiation
...
filling buffer, max size 131072 bytes
...
request body exceeds maximum size (131072) for SSL buffer
could not buffer message body to allow SSL renegotiation to proceed
...    
OpenSSL: I/O error, 5 bytes expected to read on BIO
(104)Connection reset by peer: SSL input filter read failed.
(32)Broken pipe: core_output_filter: writing data to the network
Connection closed to child 20 with standard shutdown

客户的回复是：

java.io.IOException: Server returned HTTP response code: 401 for URL

我不熟悉这个过程，所以我不确定这里是否需要重新谈判，或者我是否可以做些什么来阻止它。或者也许我可以让客户端等到重新协商完成后再发送应用程序数据？以下是客户端代码的摘录（删除了错误处理）：

        URL url = new URL("my url goes here");
        con = (HttpsURLConnection) url.openConnection();
        con.setSSLSocketFactory(getMyCustomClientCertSocketFactory());
        con.setRequestMethod("PUT");
        con.setDoOutput(true);
        con.connect();
        writer = new OutputStreamWriter(con.getOutputStream());
        writer.write(xml);
        writer.close();

        parseServerResponse(con.getInputStream());

我想也许我需要使用像SSLSocket这样的低级API并利用HandshakeCompletedListener？

我也想知道Apache SSLVerifyDepth指令是否与重新协商的原因有关。我在每个目录上下文（只有一个上传目录）中获得了值为2的指令，Apache手册对此进行了说明：

在每个目录的上下文中，它会强制重新进行SSL重新协商读取HTTP请求后重新配置客户端验证深度但在发送HTTP响应之前。

这里要求的是Java调试输出：

keyStore is : 
keyStore type is : jks
keyStore provider is : 
init keystore
init keymanager of type SunX509
trustStore is: C:\Program Files\Java\jdk1.6.0_35\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is : 
init truststore
adding as trusted cert:
 ...
trigger seeding of SecureRandom
done seeding SecureRandom
***
found key for : key-alias
chain [0] = [
[
...
]
***
trigger seeding of SecureRandom
done seeding SecureRandom
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
%% No cached client session
*** ClientHello, TLSv1
RandomCookie:  ...
Session ID:  {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
***
main, WRITE: TLSv1 Handshake, length = 75
main, WRITE: SSLv2 client hello message, length = 101
main, READ: TLSv1 Handshake, length = 81
*** ServerHello, TLSv1
RandomCookie:  ...
Session ID:  ...
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
%% Created:  [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
** TLS_RSA_WITH_AES_128_CBC_SHA
main, READ: TLSv1 Handshake, length = 4392
*** Certificate chain
chain [0] = [
[
...
Certificate Extensions: 8
[1]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
AuthorityInfoAccess [
  [
   accessMethod: ...
   accessLocation: URIName: ...
   accessMethod: ...
   accessLocation: URIName: ...
]

[2]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
...
]
]
[3]: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
  CA:false
  PathLen: undefined
]
[4]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
  [DistributionPoint:
     [URIName: ...
]]
[5]: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
  [CertificatePolicyId: ...
[PolicyQualifierInfo: [
  qualifierID: ...
  qualifier: ...
]]  ]
]
[6]: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
  serverAuth
  clientAuth
]
[7]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_Encipherment
]
[8]: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
  DNSName: ...
]
]
  Algorithm: [SHA1withRSA]
  Signature:
...
]
...
***
main, READ: TLSv1 Handshake, length = 4
*** ServerHelloDone
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
main, WRITE: TLSv1 Handshake, length = 518
SESSION KEYGEN:
PreMaster Secret:
...
CONNECTION KEYGEN:
Client Nonce:
...
Server Nonce:
...
Master Secret:
...
Client MAC write Secret:
...
Server MAC write Secret:
...
Client write key:
...
Server write key:
...
Client write IV:
...
Server write IV:
...
main, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
verify_data:  { 18, 162, 18, 251, 82, 111, 87, 133, 53, 240, 114, 155 }
***
main, WRITE: TLSv1 Handshake, length = 48
main, READ: TLSv1 Change Cipher Spec, length = 1
main, READ: TLSv1 Handshake, length = 48
*** Finished
verify_data:  { 46, 206, 8, 40, 63, 252, 99, 190, 251, 183, 110, 201 }
***
%% Cached client session: [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
main, WRITE: TLSv1 Application Data, length = 256
main, WRITE: TLSv1 Application Data, length = 32
main, WRITE: TLSv1 Application Data, length = 16416
main, WRITE: TLSv1 Application Data, length = 16416
...
main, WRITE: TLSv1 Application Data, length = 16416
main, WRITE: TLSv1 Application Data, length = 16416
main, WRITE: TLSv1 Application Data, length = 512
main, READ: TLSv1 Application Data, length = 304

这里要求的是getMyCustomClientCertSocketFactory源（从PEM文件中获取证书和密钥）：

public static SSLSocketFactory getMyCustomClientCertSocketFactory(String pemPath,
        boolean verifyPeer)
        throws NoSuchAlgorithmException, FileNotFoundException, IOException,
        KeyStoreException, CertificateException, UnrecoverableKeyException,
        KeyManagementException, InvalidKeySpecException {
    SSLContext context = SSLContext.getInstance("TLS");

    byte[] certAndKey = IOUtil.fileToBytes(new File(pemPath));
    byte[] certBytes = parseDERFromPEM(certAndKey,
            "-----BEGIN CERTIFICATE-----", "-----END CERTIFICATE-----");
    byte[] keyBytes = parseDERFromPEM(certAndKey,
            "-----BEGIN PRIVATE KEY-----", "-----END PRIVATE KEY-----");

    X509Certificate cert = generateX509CertificateFromDER(certBytes);
    RSAPrivateKey key = generateRSAPrivateKeyFromDER(keyBytes);

    KeyStore keystore = KeyStore.getInstance("JKS");
    keystore.load(null);
    keystore.setCertificateEntry("cert-alias", cert);
    keystore.setKeyEntry("key-alias", key, "changeit".toCharArray(),
            new Certificate[]{cert});

    KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
    kmf.init(keystore, "changeit".toCharArray());

    KeyManager[] km = kmf.getKeyManagers();

    TrustManager[] tm = null;

    if (!verifyPeer) {
        tm = new TrustManager[]{new TrustyTrustManager()};
    }

    context.init(km, tm, null);

    return context.getSocketFactory();
}

Answer 1

似乎Sun Java中内置的HttpsUrlConnection工具无法以服务器友好的方式处理具有客户端证书方案的大型HTTP PUT（即，不会使服务器SSL重新协商缓冲区溢出）。

我检查了curl正在做什么以查看“服务器友好意味着什么”，结果发现有一个名为“Expect”的HTTP 1.1标头，其卷曲发送的值为“100-continue”（请参阅规范{{3} }）。这个标题基本上说“我有一个巨大的有效载荷，但在我发送它之前请告诉我你是否可以处理它”。这使端点有时间在发送有效负载之前重新协商客户端证书。

在Sun HttpUrlConnection实现中，似乎不允许此标头，并且实际上是在受限标头列表中;这意味着即使您使用HttpUrlConnection.setRequestProperty方法设置它，标头也不会实际发送到服务器。您可以使用系统属性sun.net.http.allowRestrictedHeaders覆盖受限制的标头，但是客户端只是因为套接字异常而崩溃，因为Sun实现不知道如何处理这部分协议。

有趣的是，似乎Java的OpenJDK实现确实支持这个头。此外，Apache HTTP Client库支持此标头（http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.20）;我已经使用Apache HTTP客户端库实现了一个测试程序，它可以使用客户端证书和Expect头成功执行大文件的HTTP PUT请求。

总结一下，解决方案是：

将Apache SSLRenegBufferSize指令设置为一个巨大的数字（如64MB）。默认值为128K。此解决方案可能会产生拒绝服务风险
配置始终需要客户端证书的主机，而不是只有少数目录需要客户端证书的主机。这样可以避免重新谈判。这在我的场景中不是一个好的选择，因为大多数用户都是匿名或用户名/密码验证。只有一个上传目录可用于编程上传文件。我们必须为这个目录创建一个具有自己的SSL证书的新虚拟主机。
使用支持HTTP 1.1 Expect标头的客户端。不幸的是，Sun Java不支持开箱即用。必须使用第三方，例如Apache HTTP Component Client库，或使用Java套接字API滚动您自己的解决方案。
通过最初发出不具有大负载的HTTP请求，但导致重新协商发生，然后重用HTTP PUT的连接，利用HTTP 1.1持久连接（使用keep-alive进行流水线操作）。理论上，客户端应该能够在上载目录中发出HTTP HEAD或OPTIONS，然后重用相同的连接来执行PUT。为了使其工作，持久连接池可能只需要包含一个连接，以避免“启动”一个连接，然后为PUT发出另一个连接。但是，似乎HttpUrlConnection类不会保留/重用涉及客户端证书或SSL的持久连接，因为我无法使此解决方案起作用。见（http://hc.apache.org/）。

Answer 2

java.io.IOException：服务器返回HTTP响应代码：401为URL

这是一个应用程序错误。它不是由SSL层引起的。我不确定为什么你会收到401 Unauthorized更大的文件，但你也省略了getMyCustomClientCertSocketFactory()的内容你也尝试过另一种方法，例如POST？你有同样的问题吗？

Answer 3

根据现在提供的所有额外信息，我认为你应该用多个块而不是一个来编写XML。目前你正在写一个块，它将被SSL分成16k块，由于某种原因（它不应该）窒息Apache。我会尝试不超过4k的块大小。调整块大小直到它工作。

一旦超过这个问题，您可能会发现客户端证书问题。不要气馁，这证明你至少解决了这个问题。

使用客户端证书进行SSL重新协商会导致服务器缓冲区溢出

3 个答案: