Android Boring SSL

成义随笔

 关注

阅读 45

2023-10-20

前期设置

SSLContext.getInstance(“TLS”)

首先通过SSLContext.getInstance("TLS")获取SSLContext, 此时的SSLContext中的SSLContextSpi是OpenSSLContextImpl, 在OpenSSLContextImpl构造时, 构造了ClientSessionContext并记录在OpenSSLContextImpl.clientSessionContext. 而在ClientSessionContext构造时, 其父类AbstractSessionContext的构造函数中, 调用了底层的NativeCrypto.SSL_CTX_new()创建了SSL_CTX并记录在OpenSSLContextImpl.super.sslCtxNativePointer中(主要步骤):

  • 调用TLS_with_buffers_method()获取SSL_METHOD:

      static const SSL_METHOD kMethod = {
      0,
      &kTLSProtocolMethod,
      &ssl_noop_x509_method,
  };

  • 通过SSL_CTX_new()创建SSL_CTX并进行一系列设置, 其中, SSL_CTX.method设置为kMethod:

    • SSL_CTX.method设置为kTLSProtocolMethod(类型为SSL_PROTOCOL_METHOD)

    • SSL_CTX.x509_method设置为ssl_noop_x509_method(类型为SSL_X509_METHOD)

    • 其中: kTLSProtocolMethod的定义:

      static const SSL_PROTOCOL_METHOD kTLSProtocolMethod = {
    false /* is_dtls */,
    tls_new, // 初始化 SSL, 创建 SSL_HANDSHAKE
    tls_free,
    tls_get_message, // PEEK 一个 SSLMessage
    tls_next_message, // 读取一个 SSLMessage
    tls_has_unprocessed_handshake_data,
    tls_open_handshake,
    tls_open_change_cipher_spec,
    tls_open_app_data,
    tls_write_app_data, // 加密明文的 app 数据并写到输出
    tls_dispatch_alert,
    tls_init_message, // 初始化一个 SSLMessage
    tls_finish_message,// 销毁一个 SSLMessage
    tls_add_message, // 将 SSLMessage 添加到输出
    tls_add_change_cipher_spec,
    tls_flush_flight, // 冲刷未发送的数据到 BIO
    tls_on_handshake_complete,
    tls_set_read_state, // 设置 SSL.s3->aead_write_ctx
    tls_set_write_state, // 设置 SSL.s3->aead_read_ctx
};

      该数据结构设计的方法将会经常出现在后文当中

  • 通过SSL_CTX_set_info_callback()设置监听SSL连接状态对应的回调函数为: info_callback, 其调用的上层接口为: ConscryptEngine.onSSLStateChange()

  • 通过SSL_CTX_set_cert_cb()设置证书回调为: cert_cb, 其调用的上层接口为: ConscryptEngine.clientCertificateRequested() -> NativeSsl.chooseClientCertificate()

SSLContext.init()

上层调用SSLContext.init() -> OpenSSLContextImpl.engineInit(), 此时创建了SSLParametersImpl并记录了上层传递的X509KeyManager和X509TrustManager.

创建SSLParametersImpl时, 其clientSessionContext成员(类型是ClientSessionContext)

SSLContext.getSocketFactory()

上层调用SSLContext.getSocketFactory()获取SSLSocketFactory(实际是OpenSSLSocketFactoryImpl), OpenSSLSocketFactoryImpl保存了SSLParametersImpl

SSLSocketFactory.createSocket()

上层调用SSLSocketFactory(实际是OpenSSLSocketFactoryImpl)的createSocket()方法, 经过Platform.createEngineSocket()创建Java8EngineSocket(其父类是ConscryptEngineSocket), 其父类的newEngine方法创建ConscryptEngine, 此时将SSLParametersImpl克隆一份, 并传入. ConscryptEngine在构造时, 将通过newSsl() -> NativeSsl.newInstance()实例化NativeSsl, SSLParametersImpl将保存在NativeSsl.parameters, 其基本引用关系:
ConscryptEngineSocket.engine: Java8EngineSocket
ConscryptEngineSocket.engine.ssl: NativeSsl
ConscryptEngineSocket.engine.ssl.parameters: SSLParametersImpl

NativeSsl.newInstance()

  • 通过parameters.getSessionContext()获取了ClientSessionContext结构体地址
  • 调用ClientSessionContext.newSsl(), 传入ClientSessionContext, 创建SSL结构体, 其底层调用为NativeCrypto.SSL_new(), 此处底层调用到: NativeCrypto_SSL_new():
    • 通过to_SSL_CTX()还原指针ssl_ctx_address为: SSL_CTX
    • 将SSL_CTX传入SSL_new()以创建SSL结构体
    • 通过SSL_set_custom_verify()设置SSL的回调函数为:cert_verify_callback(), 该方法负责完成对服务端证书的验证, 在cert_verify_callback()中, 回调上层的NativeCrypto.verifyCertificateChain()
  • SSL结构体被传递给NativeCrypto.SSL_new(), 保存到NativeSsl.ssl, 从顶层向下:ConscryptEngineSocket.engine.ssl.ssl

BioWrapper 的创建

这里注意下 ConscryptEngine.networkBio(), 它的类型是BioWrapper, 是很重要的角色, 它负责处理所有 “加密” 的数据, 通过NativeSsl.newBio()创建, 更底层的方法是:NativeCrypto.SSL_BIO_new():

  • 通过BIO_new_bio_pair()创建一对BIO:internal_bio和network_bio, 此时创建的BIO.mehtod被设置为methods_biop, 因此BIO.mehtod->bread被设置为bio_read, 而BIO.mehtod->bwrite被设置为: bio_write
  • 通过SSL_set_bio()将internal_bio配置给了SSL, 保存在(SSL.wbio和SSL.rbio)
  • 将network_bio引用在BioWrapper.bio

ConscryptEngine.networkBio.bio非常重要, 它将在后文经常被提到.

ConscryptEngineSocket.startHandshake()

上层调用ConscryptEngineSocket.startHandshake()开始执行MTLS协商:

  • 创建 SSLInputStream并保存到ConscryptEngineSocket.in, 在此过程中
    • 通过ByteBuffer.allocateDirect分配与NativeSsl交互的DirectByteBuffer, 此处的 buffer 对于 JNI 来说是没有拷贝成本的. DirectByteBuffer保存到 ConscryptEngineSocket.in.fromEngine
    • 通过 ByteBuffer.allocate()分配与SocketInputStream进行通信的的HeapByteBuffer, HeapByteBuffer保存到 ConscryptEngineSocket.in.fromSocket
  • 创建 SSLOutputStream并保存到ConscryptEngineSocket.out, 在此过程中:
    • 通过 ByteBuffer.allocate()分配与SocketOutputStream进行通信的的HeapByteBuffer, HeapByteBuffer保存到 ConscryptEngineSocket.out.target
  • 调用SSLInputStream.processDataFromSocket()获取数据, 调用readFromSocket()从SocketInputStream读取数据, 然后调用ConscryptEngine.unwrap()处理读取到的数据, 细节见解密小节

TLS协商

TLS协商的主循环:

NativeCrypto_ENGINE_SSL_read_direct() [libjavacrypto.so] ->
    ::SSL_read() [libssl.so] ->
        ssl_read_impl() ->
            ::SSL_do_handshake() ->
                bssl::ssl_run_handshake()

该函数是一个循环, 该循环依次调用SSL_HANDSHAKE.ssl->do_handshake方法, 对于客户端, 该方法为ssl_client_handshake(), 在该方法中, 初始状态为state_start_connect()

state_start_connect(TLS)

state_start_connect对应的执行函数为do_start_connect():

  • 初始化SSL.s3结构体
  • 调用ssl_setup_key_shares()初始化 keys_shares
  • 调用ssl_setup_extension_permutation()初始化扩展
  • 调用ssl_encrypt_client_hello()加密 client_hello
  • 调用ssl_add_client_hello()将 client_hello 附加到消息池(SSL.s3->write_buffer中)
  • 返回状态为: ssl_hs_flush
    如果该状态顺利执行结束, 则向上返回给ssl_run_handshake()的结果是ssl_hs_flush, 因此ssl_run_handshake()继续执行SSL_HANDSHAKE.ssl->method->flush_flight方法, 该方法为kTLSProtocolMethod.flush_flight即tls_flush_flight(), 进一步调用ssl_write_buffer_flush() -> tls_write_buffer_flush() -> BIO_write(), 将ssl.s3->write_buffer数据写入到SSL.wbio的BIO中, 如前文所述, 该BIO即internal_bio, 其关联的对象为network_bio, 至此上层就可以通过NativeCrypto.ENGINE_SSL_read_BIO_direct()读取到数 BoringSSL 需要发送的数据了.

state_enter_early_data(TLS)

执行do_enter_early_data(), 基本没有做太多事情, 判断SSL_HANDSHAKE.early_data_offered为空就直接切换状态到state_read_server_hello

state_read_server_hello(TLS)

执行 do_read_server_hello(), 并读取TLS数据, 调用ssl_parse_server_hello()解析协议头, 获取版本号, 本文的案例显然是MTLSv1.3, 则切换状态到 state_tls13

state_tls13(TLS)

执行do_tls13() -> tls13_client_handshake(), 该函数也是一个循环, 如果SSL_HANDSHAKE.tls13_state不为state_done就循环执行后续的状态切换, 初始状态为: state_read_hello_retry_request

state_read_hello_retry_request(0, TLSv1.3 start)

调用do_read_hello_retry_request():

  • 调用parse_server_hello_tls13()解析消息头

  • 调用SSL_get_cipher_by_value()获取服务器要求的算法: SSL_CIPHER, 本文的案例是TLS1_3_RFC_AES_128_GCM_SHA256, 协议 id 为 4865, 也就是:

    static constexpr SSL_CIPHER kCiphers[] = {
    // Cipher 1301
    {
      TLS1_3_RFC_AES_128_GCM_SHA256,
      "TLS_AES_128_GCM_SHA256",
      TLS1_3_CK_AES_128_GCM_SHA256,
      SSL_kGENERIC,
      SSL_aGENERIC,
      SSL_AES128GCM,
      SSL_AEAD,
      SSL_HANDSHAKE_MAC_SHA256,
    },
    ...
};

  • 将 SSL_CIPHER保存到SSL_HANDSHAKE.new_cipher

  • 切换状态到state_read_server_hello

state_read_server_hello(2)

调用do_read_server_hello(), 该函数做了很多工作:

  • 复制并保存 server_random
  • 将SSL_HANDSHAKE.new_cipher保存到SSK_HANDSHAKE.new_session->cipher
  • 调用ssl_ext_key_share_parse_serverhello()从server_hello中解析出dhe_secret
  • 调用tls13_advance_key_schedule()派生秘钥并保存到SSL_HANDSHAKE.secret_
  • 调用tls13_derive_handshake_secrets()派生秘钥并保存到SSL_HANDSHAKE.client_handshake_secret_
  • 调用tls13_set_traffic_key()将SSL_HANDSHAKE.client_handshake_secret_设置到SSL:
    • 调用ssl_cipher_get_evp_aead()确定EVP_AEAD, 该结构体主要为了确定秘钥长度
    • 调用ssl_session_get_digest()获取EVP_MD用于秘钥派生
    • 以"key"作为label调用hkdf_expand_label()派生秘钥
    • 以"iv"作为label调用hkdf_expand_label()派生初始向量
    • 调用SSLAEADContext::Create()并传入SSL, Cipher, 秘钥, iv, 创建SSLAEADContext
    • 调用SSL.method->set_read_state即tls_set_read_state()设置SSLAEADContext到SSL_HANDSHAKE.ssl->s3->aead_read_ctx
    • 保存SSL_HANDSHAKE.client_handshake_secret_到SSL.s3->read_traffic_secret
    • 调用SSL.method->set_write_state即tls_set_write_state()设置SSLAEADContext到SSL_HANDSHAKE.ssl->s3->aead_write_ctx
    • 保存SSL_HANDSHAKE.client_handshake_secret_到SSL.s3->write_traffic_secret

从此刻开始, 与服务器的数据往来都使用: SSL_HANDSHAKE.client_handshake_secret_ 加密

state_read_encrypted_extensions(3)

state_read_certificate_request(4)

调用do_read_certificate_request()

state_read_server_certificate(5)

调用do_read_server_certificate() -> tls13_process_certificate(), 从服务器返回的消息解析证书信息, 将证书保存到SSL_HANDSHAKE.new_session->certs

state_read_server_certificate_verify(6)

调用do_read_server_certificate_verify() -> ssl_verify_peer_cert() -> SSL_HANDSHAKE.ssl->config->custom_verify_callback, 根据前文, SSL_HANDSHAKE.ssl->config->custom_verify_callback已经被SSL_set_custom_verify()设置为:cert_verify_callback():

  • 调用SSL_get0_peer_certificates()获取上文刚解析到的服务器证书链:SSL_HANDSHAKE.new_session->certs

  • 调用上层: ConscryptEngine.verifyCertificateChain() -> Platform.checkServerTrusted() -> X509Trustmanager.checkServerTrusted(), 其中ConscryptEngine继承了NativeCrypto.SSLHandshakeCallbacks, X509Trustmanager.checkServerTrusted()为用户自定义的服务器证书验证方法.

state_read_server_finished(8)

调用do_read_server_finished():

  • 调用tls13_advance_key_schedule()更新加密算法
  • 调用tls13_derive_application_secrets() -> derive_secret("CLIENT_TRAFFIC_SECRET_0")派生交换凭据的秘钥, 保存到SSL_HANDSHAKE.client_traffic_secret_0_

注意, 此时的SSL_HANDSHAKE.client_traffic_secret_0_并没有作为会话秘钥, 这是因为还没有发送本地的凭据(这里我们只讨论 MTLSv1.3 )

state_send_end_of_early_data(9)

state_send_client_encrypted_extensions(10)

state_send_client_certificate(11)

调用do_send_client_certificate() -> SSL_HANDSHAKE.ssl->cert->cert_cb, 该回调被SSL_CTX_set_cert_cb()设置为external/conscrypt/common/src/jni/main/cpp/conscrypt/native_crypto.cc::cert_cb()将在如下环节被调用:

bssl::ssl_run_handshake() ->
    bssl::ssl_client_handshake() ->
        bssl::tls13_client_handshake() ->
            bssl::do_send_client_certificate() ->
                cert_cb() [libjavacrypto.so]

如上文cert_cb()调用的上层接口为: ConscryptEngine.clientCertificateRequested() -> NativeSsl.chooseClientCertificate(), 其首先调用ConscryptEngineSocket.chooseClientAlias()选取本地的证书别名, 而ConscryptEngineSocket.chooseClientAlias()实际上是调用了X509KeyManager.chooseClientAlias(), 然后通过setCertificate()设置本地的证书&密钥, 参数为证书与秘钥的别名:

  • 从SSLParametersImpl中获取X509KeyManager

  • 从X509KeyManager中获取PrivateKey, 这是上层应用自定义的

  • 从X509KeyManager中获取所有可用的X509Certificate, 即X509Certificate[]

  • 从PrivateKey转换到OpenSSLKey, 这里调用: OpenSSLKey.fromPrivateKeyForTLSStackOnly() -> fromECPrivateKeyForTLSStackOnly() -> OpenSSLECPrivateKey.wrapJCAPrivateKeyForTLSStackOnly(), 首先调用OpenSSLECGroupContext.getInstance()从ECParameterSpec获取OpenSSLECGroupContext. 创建OpenSSLKey, 调用NativeCrypto_getECPrivateKeyWrapper()产生底层的EVP_PKEY结构体, 传递OpenSSLECGroupContext作为参数:

    • 上层传递了秘钥的 Group 信息, 通过fromContextObject<EC_GROUP>()转换参数groupRef转换到EC_GROUP,

      • 通过ensure_engine_globals() -> init_engine_globals()初始化g_rsa_method和g_ecdsa_method:
        • 通过ENGINE_new()初始化g_engine
        • 通过ENGINE_set_RSA_method配置g_rsa_method给g_engine
        • 通过ENGINE_set_ECDSA_method配置g_ecdsa_method给g_engine

    • 通过EC_KEY_new_method()创建 EC_KEY结构体

    • 通过EC_KEY_set_group()配置 EC_KEY的 Group信息

    • 构造KeyExData结构体, 将上层传递的javaKey的 jobject 对象保存到刚刚创建的KeyExData.private_key字段

    • 通过EC_KEY_set_ex_data()配置KeyExData结构体到 EC_KEY

    • 通过EVP_PKEY_new()创建EVP_PKEY结构体

    • 通过EVP_PKEY_assign_EC_KEY()将EC_KEY 结构体分配给 EVP_PKEY 结构体

    • 创建的 EVP_PKEY 结构体保存到OpenSSLKey.ctx中, 所以后续将OpenSSLKey传递给底层时, 获取ctx即可
      可以看到, OpenSSLKey.ctx即EVP_PKEY, 其中:

      • EVP_PKEY.ameth被设置为ec_asn1_meth

        const EVP_PKEY_ASN1_METHOD ec_asn1_meth = {
    EVP_PKEY_EC,
    // 1.2.840.10045.2.1
    {0x2a, 0x86, 0x48, 0xce, 0x3d, 0x02, 0x01},
    7,
    &ec_pkey_meth,
    eckey_pub_decode, // 从 DER 中解码 EC-PublicKey
    eckey_pub_encode, // 编码 EC-PublicKey 到 DER
    eckey_pub_cmp, // 比较两个公钥是否相同
    eckey_priv_decode, // 从 DER 解码 EC-PrivateKey
    eckey_priv_encode, // 编码 EC-PrivateKey 到 DER
    eckey_set1_tls_encodedpoint,
    eckey_get1_tls_encodedpoint,
    eckey_opaque,
    int_ec_size,
    ec_bits,
    ec_missing_parameters,
    ec_copy_parameters, // 拷贝 ECC 秘钥参数
    ec_cmp_parameters,  // 比较 ECC 秘钥参数
    int_ec_free,
};

        其中ec_pkey_meth的类型为EVP_PKEY_METHOD, 作为EVP_PKEY的操作方法, 记录在EVP_PKEY_CTX.pmeth

        const EVP_PKEY_METHOD ec_pkey_meth = {
    EVP_PKEY_EC,
    pkey_ec_init,
    pkey_ec_copy,
    pkey_ec_cleanup,
    pkey_ec_keygen, // 生成 ECC 秘钥
    pkey_ec_sign, // 使用 EC-PrivateKey 执行签名
    pkey_ec_verify, // 使用 EC-PublicKey 验证签名
    pkey_ec_derive, // 使用 EC-PrivateKey 进行 ECDH
    pkey_ec_paramgen,
    pkey_ec_ctrl,
};

      • EVP_PKEY.pkey被设置为EC_KEY ,其中:

        • EC_KEY.ecdsa_meth被设置为上文提及的: g_ecdsa_method, 其中:
          • EC_KEY.ecdsa_meth->sign为EcdsaMethodSign()
          • EC_KEY.ecdsa_meth->flags为ECDSA_FLAG_OPAQUE
        • EC_KEY.ex_data.sk被设置为上文体积的: KeyExData结构体

  • 调用NativeCrypto.setLocalCertsAndPrivateKey()设置上文获取的X509Certificate(转换到byte[][])和OpenSSLKey到底层

  • 接下来看NativeCrypto.setLocalCertsAndPrivateKey, 改函数对应: NativeCrypto_setLocalCertsAndPrivateKey():

    • 获取SSL结构体
    • 通过fromContextObject()获取上层的EVP_PKEY结构体(从上文提及的OpenSSLKey.ctx中获取)
    • 依次获取上层传递的证书数据到CRYPTO_BUFFER结构体
    • 通过SSL_set_chain_and_key() -> cert_set_chain_and_key():
      • 通过check_leaf_cert_and_privkey()检查私钥与证书是否配对, 这里需要注意的是, 其中的一个检查步骤为ssl_compare_public_and_private_key(), 该函数中做了如下逻辑:
          if (EVP_PKEY_is_opaque(privkey)) {
    // We cannot check an opaque private key and have to trust that it
    // matches.
    return true;
  }
        这里因为EVP_PKEY.ameth->pkey_opaque为ec_asn1_meth.pkey_opaque也就是eckey_opaque该函数通过eckey_opaque()判断EVP_PKEY.pkey也就是EC_KEY中的ECDSA_METHOD.flags是否设置了ECDSA_FLAG_OPAQUE, 上文提到EC_KEY.ecdsa_meth.flags已经设置了ECDSA_FLAG_OPAQUE, 所以这里不会报错
        • 将std::vector<CRYPTO_BUFFER*>的证书信息和EVP_PKEY的私钥信息配置给SSL结构体, 这里:
        • SSL.config->cert->chain保存数个CRYPTO_BUFFER
        • SSL.config->cert->privatekey保存EVP_PKEY
        • SSL.config->cert->key_method设置为空

state_send_client_certificate_verify(12)

执行do_send_client_certificate_verify() -> ssl_private_key_sign()中:

  • 执行setup_ctx() -> EVP_DigestSignInit() -> do_sigver_init() -> EVP_PKEY_CTX_new(), 因为EVP_PKEY.ameth->pkey_method为ec_asn1_meth.pkey_method, 即ec_pkey_meth, 因此创建的EVP_PKEY_CTX.pmeth为ec_pkey_meth, 创建的EVP_MD_CTX在do_sigver_init()中设置到EVP_MD_CTX.pctx
  • 执行EVP_DigestSign() -> EVP_DigestSignFinal() -> EVP_PKEY_sign() -> EVP_PKEY.pmeth->sign, 即上一步骤提及的ec_pkey_meth.sign即pkey_ec_sign(), 该方法先 从EVP_PKEY获取EC_KEY, 然后调用ECDSA_sign(), 传入EC_KEY, 如果设置了EC_KEY.ecdsa_meth->sign方法, 则调用, 如上文, 这里调用EcdsaMethodSign():
    • 通过EcKeyGetKey() -> EC_KEY_get_ex_data从EC_KEY中获取KeyExData结构体中的PrivateKey对象对应的jobject
    • 调用ecSignDigestWithPrivateKey(), 并将上一步骤获取的PrivateKey对象以及签名数据做为参数, 对应的上层调用为: CryptoUpcalls.ecSignDigestWithPrivateKey() -> signDigestWithPrivateKey():
      • 首先通过Signature.getInstance()获取默认签名算法, 然后调用Signature.initSign()设置PrivateKey, 执行 Signature.update()更新签名数据后, 执行Signature.sign()进行签名. 这里的 Signature和上层自定义的PrivateKey是配套的, 这部分内容, 在后续介绍 Security.Provider时再介绍.

state_complete_second_flight(13)

调用do_complete_second_flight():

  • 调用tls13_add_finished()发送协商结束消息
  • 调用tls13_set_traffic_key()设置SSL_HANDSHAKE.client_traffic_secret_0_为新的会话密钥

state_done(14, TLSv1.3 end)

state_finish_client_handshake(TLS)

调用do_finish_client_handshake(), 这里将SSL.s3->established_session设置为SSL.session

加密与解密

SSLOutputStream.write() 时的加密

上层调用: SSLOutputStream.write() -> writeInternal() -> ConscryptEngine.wrap(), ConscryptEngine.wrap()的语义是: 明文到加密数据的: 加密, 分两个步骤:

  • 首先是writePlaintextData() -> writePlaintextDataHeap() -> writePlaintextDataDirect()将数据往NativeSsl写, 更底层的操作是NativeCrypto.ENGINE_SSL_write_direct()
  • 然后是readEncryptedData() -> readEncryptedDataDirect()从BioWrapper读取数据, 更底层的操作是NativeCrypto.ENGINE_SSL_read_BIO_direct()

从这里也可以总结出: 对于加密数据, 统一由 BioWrapper传递, 对于明文数据, 统一通过NativeSsl直接传递, 这里的BioWrapper也是后续 MTLS 协商结束后的 AES 加密通道.

NativeCrypto.ENGINE_SSL_write_direct() -> 
    NativeCrypto_ENGINE_SSL_write_direct() [libjavacrypto.so] -> 
        ::SSL_write() [libssl.so]

此处, SSL.method->write_app_data为kTLSProtocolMethod中的tls_write_app_data(), 因此

    ::SSL_write() [libssl.so] -> 
        bssl::tls_write_app_data() ->
            bssl::do_tls_write()

此处分两个步骤:

  • 首先处理数据的加密:bssl::do_tls_write() -> bssl::tls_seal_record() -> bssl::tls_seal_scatter_record() -> bssl::do_seal_record(), 此处SSL.s3->aead_write_ctx为: SSLAEADContext, 因此:bssl::SSLAEADContext::SealScatter()被调用, 这里的ctx_为EVP_AEAD_CTX, 而EVP_AEAD_CTX.aead为EVP_aead_aes_256_gcm_tls13, 因此EVP_AEAD_CTX.aead->seal_scatter为aead_aes_gcm_tls13_seal_scatter() [libcrypto.so], 这里有硬件加速的部分, 简单列出调用的堆栈, 具体细节本文不做讨论:
    EVP_AEAD_CTX_seal_scatter() [libcrypto.so] ->
        aead_aes_gcm_tls13_seal_scatter() ->
            aead_aes_gcm_seal_scatter() ->
                aead_aes_gcm_seal_scatter_impl() ->
                    CRYPTO_gcm128_encrypt()
  • 然后处理数据的发送: bssl::do_tls_write() -> bssl::tls_seal_record() -> bssl::tls_seal_scatter_record() -> bssl::ssl_write_buffer_flush() -> tls_write_buffer_flush() -> BIO_write(), 将ssl.s3->write_buffer数据写入到SSL.wbio的BIO中, 如前文所述, 该BIO即internal_bio, 其关联的对象为network_bio, 至此上层就可以通过NativeCrypto.ENGINE_SSL_read_BIO_direct()读取到数 BoringSSL 需要发送的数据了.
NativeCrypto.ENGINE_SSL_read_BIO_direct() ->
    NativeCrypto_ENGINE_SSL_read_BIO_direct() [libjavacrypto.so] -> 
        ::BIO_read() ->
            bio_read() [external/boringssl/src/crypto/bio/pair.c]

这里从network_bio读取internal_bio的加密数据.

SSLInputStream.read() 时的解密

上层调用: SSLInputStream.read() -> readUntilDataAvailable() -> processDataFromSocket() -> ConscryptEngine.unwrap(), ConscryptEngine.unwrap()的语义是: 加密数据到明文的: 解密, ,unwrap()分两个步骤进行:
* 首先是writeEncryptedData() -> writeEncryptedDataHeap() -> writeEncryptedDataDirect()将数据往BioWrapper写, 更底层的操作是NativeCrypto.ENGINE_SSL_write_BIO_direct()
* 然后是readPlaintextData() -> readPlaintextDataDirect()从NativeSsl读取数据, 更底层的操作是NativeCrypto.ENGINE_SSL_read_direct()

NativeCrypto.ENGINE_SSL_write_BIO_direct() ->
    NativeCrypto_ENGINE_SSL_write_BIO_direct() [libjavacrypto.so] -> 
        ::BIO_write() ->
            bio_write() [external/boringssl/src/crypto/bio/pair.c]

这里通过network_bio写入加密数据到internal_bio

NativeCrypto.ENGINE_SSL_read_direct() ->
    NativeCrypto_ENGINE_SSL_read_direct() [libjavacrypto.so] -> 
        ::SSL_read() ->
            ::SSL_peek() ->
                ssl_read_impl()

这里开始分两部分:

  • 首先处理数据的读取, 从BIO中读取上层写入的加密数据
ssl_read_impl() ->
    bssl::ssl_handle_open_record() ->
        bssl::ssl_read_buffer_extend_to() ->
            tls_read_buffer_extend_to() ->
                BIO_read() [libcrypto.so] ->
                    bio_read()
  • 然后处理数据的解密, ssl_read_impl() -> tls_open_app_data() -> tls_open_record(), 此处SSL.s3->aead_read_ctx为: SSLAEADContext, 因此:bssl::SSLAEADContext::Open() -> EVP_AEAD_CTX_open() -> EVP_AEAD_CTX_open_gather()被调用, 这里的ctx_为EVP_AEAD_CTX, 而EVP_AEAD_CTX.aead为EVP_aead_aes_256_gcm_tls13, 因此EVP_AEAD_CTX.aead->open_gather为aead_aes_gcm_open_gather() [libcrypto.so], 这里有硬件加速的部分, 简单列出调用的堆栈, 具体细节本文不做讨论:
bssl::tls_open_record() ->
    bssl::SSLAEADContext::Open() ->
        EVP_AEAD_CTX_open() ->
            EVP_AEAD_CTX_open_gather() ->
                aead_aes_gcm_open_gather_impl() ->
                    CRYPTO_gcm128_decrypt_ctr32()

相关推荐

leetcode620. Not Boring Movies

Java旺 93 0 0

【BestCoder】 HDOJ 5056 Boring count

米小格儿 26 0 0

[leetcode]620. Not Boring Movies

乐百川 40 0 0

HDU 4358 Boring counting 莫队算法

zibianqu 30 0 0

LeetCode-SQL-620. Not Boring Movies

凶猛的小白兔 127 0 0

至今我自己犯过的boring bug

无愠色 72 0 0

CodeForces - 239D Boring Partition（思维）

Mhhao 124 0 0

CERC2012 D - Non-boring sequences 暴力

seuleyang 130 0 0

Android ssl单向认证和双向认证切换

棒锤_45f2 78 0 0

android studio ERROR: SSL peer shut down incorrectly问题

君之言之 56 0 0

精彩评论（0）

0 0 举报