展开

关键词

HandShake

相关内容

云服务器

云服务器

腾讯云服务器(CVM)为您提供安全可靠的弹性云计算服务。只需几分钟,您就可以在云端获取和启用云服务器,并实时扩展或缩减云计算资源。云服务器 支持按实际使用的资源计费,可以为您节约计算成本。
  • MySql协议详解-HandShake握手篇

    MySql协议详解-HandShake握手篇各位有没有对Cobar、MyCat这些MySqlProxy感到新奇。反正笔者在遇到这些proxy时,感受到其对代码的无侵入兴感到大为惊奇。HandShake协议下图是笔者整理的HandShake协议交互流程 ? Step1:客户端向DB发起TCP握手。 Step2:三次握手成功。与通常流程不同的是,由DB发送HandShake信息。Step3:客户端根据HandShake包里面的加密seed对MySql登录密码进行摘要后,构造Auth认证包发送给DB。(3)Body则是最终传递信息的地方,如上图中的handshake包。
    来自:
    浏览:751
  • TLS 1.3 Handshake Protocol (下)

    这些消息使用从 sender_handshake_traffic_secret 派生出来的密钥进行加密。请注意,基于证书的 Client 身份验证在 PSK 握手流中不可用(包括 0-RTT) CertificateVerify: 根据 Transcript-Hash(Handshake Context,Mn) = Hash(message_hash || * Handshake type * 00 00 Hash.length || * Handshake message length (bytes)Post-Handshake MessagesTLS 还允许在主握手后发送其他的消息。这些消息使用握手内容类型,并使用适当的应用程序流量密钥进行加密。(2) Post-Handshake Authentication当 Client 发送了 post_handshake_auth 扩展(参见第4.2.6节)时,Server 可以在握手完成后随时通过发送
    来自:
    浏览:525
  • 广告
    关闭

    云+社区杂货摊第四季上线啦~

    攒云+值,TOP 100 必得云+社区定制视频礼盒

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到
  • git schnnel failed to receive handshake, SSLTLS connection failed

    fatal: unable to access ‘https:github.comi042416KnowlegeRepository.git’: schnnel: failed to receive handshake
    来自:
    浏览:1396
  • socket.handshake.address undefined for Socket.io 2.0

    我正在尝试使用socket.handshake.address检索客户端IP地址,但它总是输出值undefined ..我不确定io.on的位置是否是导致错误的主要原因。但我需要帮助输出一些价值。sent_msg = : + sent_msg; io.sockets.emit(update messages, sent_msg); callback(); }); clientIP = socket.handshake.address编辑:我能够console.log(socket.handshake.address),但看起来它输出:: 1。
    来自:
    回答:1
  • TLS 1.3 Handshake Protocol (上)

    type * uint24 length; * remaining bytes in message * select (Handshake.msg_type) { case client_helloPost-Handshake Client Authenticationpost_handshake_auth 扩展用于表明 Client 愿意握手后再认证。struct {} PostHandshakeAuth;复制代码post_handshake_auth 扩展名中的 extension_data 字段为零长度。7.这些消息是加密的,通过从 server_handshake_traffic_secret 中派生的密钥加密的。1.这是在从 server_handshake_traffic_secret 派生的密钥下加密的第一条消息。EncryptedExtensions 消息包含应该被保护的扩展。
    来自:
    浏览:773
  • 解决拉取github仓库报错“gnutls_handshake() failed”问题

    gnutls_handshake() failed: The TLS connection was non-properly terminated.最近为新配置的虚机拉取库,但是从 GitHub 拉取库总是出问题
    来自:
    浏览:3049
  • 故障分析 | Bad handshake,升级 5.7.28 引起的“血案”

    完成后应用连接测试发现页面异常,mysql error 日志显示: 2020-05-05T22:10:57.976402+08:00 2 Bad handshake 没有报错,但这条 Note 级别的日志Bad handshake,不好的握手,网上查了资料,发现和 SSL 可能有关。这时业务也发来应用日志,日志有明显的 SSL 相关报错。
    来自:
    浏览:413
  • Charles Client SSL handshake failed certificate_unknown

    抓包 Android App HTTPS Charles Client SSL handshake failed 问题解决.
    来自:
    浏览:4078
  • Cloud Foundry 运行bosh create-env时报错: TLS handshake timeout

    instance bosh0: Waiting until instance is ready: Post https:mbus:@192.168.50.6:6868agent: nethttp: TLS handshake
    来自:
    浏览:493
  • RabbitMQ - TcpConnection析构引发的一次handshake_timeout

    这非常诧异,查看rabbit-server日志看到,产生了一次handshake_timeout错误。?
    来自:
    浏览:771
  • RabbitMQ - TcpConnection析构引发的一次handshake_timeout

    这非常诧异,查看rabbit-server日志看到,产生了一次handshake_timeout错误。 ?
    来自:
    浏览:844
  • TLS协议分析 (四) handshake协议概览

    来自:
    浏览:82
  • TLS协议分析 (六) handshake协议扩展

    来自:
    浏览:78
  • Linux tcpip 源码分析 - three way handshake

    在上一篇文章中我们讲到,connect方法会发送syn消息给服务端,之后客户端会进入TCP_SYN_SENT状态。这就是tcp三次握手的第一步。接下来我们看下,服务端收到syn消息后的处理逻辑。首先,ip层在收到消息后,会调用tcp_v4_rcv方法将消息转给tcp层。 netipv4tcp_ipv4.cint tcp_v4_rcv(struct sk_buff *skb){ ... const struct iphdr *iph; const struct tcphdr *th; ... struct sock *sk; int ret; ... th = (const struct tcphdr *)skb->data; iph = ip_hdr(skb); ... sk = __inet_lookup_skb(&tcp_hashinfo, skb, __tcp_hdrlen(th), th->source, th->dest, sdif, &refcounted); ... if (sk->sk_state == TCP_LISTEN) { ret = tcp_v4_do_rcv(sk, skb); goto put_and_return; } ... return ret; ...}方法描述1. 调用__inet_lookup_skb方法,根据ip、端口等信息在全局的hashtable中找到对应的sock。2. 此时sk->sk_state应该是TCP_LISTEN状态,所以会继续调用tcp_v4_do_rcv方法。 netipv4tcp_ipv4.cint tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb){ struct sock *rsk; ... if (tcp_rcv_state_process(sk, skb)) { ... goto reset; } return 0; ...}EXPORT_SYMBOL(tcp_v4_do_rcv);该方法会继续调用tcp_rcv_state_process方法。 netipv4tcp_input.cint tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb){ ... struct inet_connection_sock *icsk = inet_csk(sk);  const struct tcphdr *th = tcp_hdr(skb);  ... switch (sk->sk_state) { ... case TCP_LISTEN: ... if (th->syn) { ... acceptable = icsk->icsk_af_ops->conn_request(sk, skb) >= 0; ... return 0; } ... } ...}EXPORT_SYMBOL(tcp_rcv_state_process);因为客户端发来的是syn消息,而服务端此时是TCP_LISTEN状态,所以该方法最终会调用icsk->icsk_af_ops->conn_request(sk, skb)方法。由第一篇文章我们可以知道,icsk->icsk_af_ops字段的值为&ipv4_specific,所以icsk->icsk_af_ops->conn_request指向的方法为tcp_v4_conn_request。 netipv4tcp_ipv4.cint tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb){ ... return tcp_conn_request(&tcp_request_sock_ops,        &tcp_request_sock_ipv4_ops, sk, skb);  ...}EXPORT_SYMBOL(tcp_v4_conn_request);该方法又调用了tcp_conn_request方法,其中前两个参数为两个结构体,内容如下 netipv4tcp_ipv4.cstruct request_sock_ops tcp_request_sock_ops __read_mostly = { .family = PF_INET, .obj_size = sizeof(struct tcp_request_sock), .rtx_syn_ack = tcp_rtx_synack, .send_ack = tcp_v4_reqsk_send_ack, .destructor = tcp_v4_reqsk_destructor, .send_reset = tcp_v4_send_reset, .syn_ack_timeout = tcp_syn_ack_timeout,}; static const struct tcp_request_sock_ops tcp_request_sock_ipv4_ops = { .mss_clamp = TCP_MSS_DEFAULT,#ifdef CONFIG_TCP_MD5SIG .req_md5_lookup = tcp_v4_md5_lookup, .calc_md5_hash = tcp_v4_md5_hash_skb,#endif .init_req = tcp_v4_init_req,#ifdef CONFIG_SYN_COOKIES .cookie_init_seq = cookie_v4_init_sequence,#endif .route_req = tcp_v4_route_req, .init_seq = tcp_v4_init_seq, .init_ts_off = tcp_v4_init_ts_off, .send_synack = tcp_v4_send_synack,};tcp_conn_request方法如下 netipv4tcp_input.cint tcp_conn_request(struct request_sock_ops *rsk_ops, const struct tcp_request_sock_ops *af_ops, struct sock *sk, struct sk_buff *skb){ ... struct request_sock *req; ... req = inet_reqsk_alloc(rsk_ops, sk, !want_cookie); ... tcp_rsk(req)->af_specific = af_ops; ... if (fastopen_sk) { ... } else { ... if (!want_cookie) inet_csk_reqsk_queue_hash_add(sk, req, tcp_timeout_init((struct sock *)req)); af_ops->send_synack(sk, dst, &fl, req, &foc, !want_cookie ? TCP_SYNACK_NORMAL : TCP_SYNACK_COOKIE); ... } ... return 0; ...}EXPORT_SYMBOL(tcp_conn_request);方法描述1. 调用inet_reqsk_alloc方法,分配并初始化一个struct request_sock实例,用于存储连接请求数据。2. 将tcp_rsk(req)->af_specific的值设置为af_ops,即&tcp_request_sock_ipv4_ops。3. 调用inet_csk_reqsk_queue_hash_add方法,将连接请求实例req添加到全局hashtable中。4. 调用af_ops->send_synack发送synack消息给客户端。我们再来看下inet_reqsk_alloc方法 netipv4tcp_input.cstruct request_sock *inet_reqsk_alloc(const struct request_sock_ops *ops, struct sock *sk_listener, bool attach_listener){ struct request_sock *req = reqsk_alloc(ops, sk_listener, attach_listener); if (req) {    struct inet_request_sock *ireq = inet_rsk(req);    ... ireq->ireq_state = TCP_NEW_SYN_RECV; ... } return req;}EXPORT_SYMBOL(inet_reqsk_alloc);该方法中要注意的就是,ireq->ireq_state的值被设置为TCP_NEW_SYN_RECV,这个后面会用到。该方法有调用了reqsk_alloc方法,继续看下。 includenetrequest_sock.hstatic inline struct request_sock *reqsk_alloc(const struct request_sock_ops *ops, struct sock *sk_listener, bool attach_listener){ struct request_sock *req; req = kmem_cache_alloc(ops->slab, GFP_ATOMIC | __GFP_NOWARN); ... if (attach_listener) { ... req->rsk_listener = sk_listener; } req->rsk_ops = ops; req_to_sk(req)->sk_prot = sk_listener->sk_prot; ... return req;}该方法需要注意的是1. req->rsk_listener字段被设置为sk_listener,即listen sock。2. req->rsk_ops被设置为ops,即&tcp_request_sock_ops。到这里tcp_conn_request方法就算分析结束了。至此,tcp三次握手的第二步结束。我们再来看下客户端在收到synack消息时是如何处理的。还是回到tcp_v4_rcv方法,此时sock的状态为TCP_SYN_SENT。 netipv4tcp_ipv4.cint tcp_v4_rcv(struct sk_buff *skb){ ... const struct tcphdr *th; struct sock *sk; ... th = (const struct tcphdr *)skb->data; ... sk = __inet_lookup_skb(&tcp_hashinfo, skb, __tcp_hdrlen(th), th->source, th->dest, sdif, &refcounted); ... ret = 0; if (!sock_owned_by_user(sk)) { ret = tcp_v4_do_rcv(sk, skb); } else if (tcp_add_backlog(sk, skb)) { ... } ... return ret; ...}方法描述1. 调用__inet_lookup_skb方法,根据ip、端口等信息,从全局hashtable中找到对应的sock。2. 调用tcp_v4_do_rcv方法,继续处理。 netipv4tcp_ipv4.cint tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb){  struct sock *rsk;  ... if (tcp_rcv_state_process(sk, skb)) {    ... goto reset; }  return 0;  ...}EXPORT_SYMBOL(tcp_v4_do_rcv);该方法又调用了tcp_rcv_state_process方法。 netipv4tcp_input.cint tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb){ ...  const struct tcphdr *th = tcp_hdr(skb);  ... switch (sk->sk_state) { ... case TCP_SYN_SENT: ... queued = tcp_rcv_synsent_state_process(sk, skb, th); ... return 0; } ...}EXPORT_SYMBOL(tcp_rcv_state_process);因为客户端此时的状态为TCP_SYN_SENT,所以该方法最终会调用tcp_rcv_synsent_state_process方法。 netipv4tcp_input.cstatic int tcp_rcv_synsent_state_process(struct sock *sk, struct sk_buff *skb, const struct tcphdr *th){ struct inet_connection_sock *icsk = inet_csk(sk); ... if (th->ack) { ... if (!th->syn) goto discard_and_undo; ... tcp_finish_connect(sk, skb); ... if (!sock_flag(sk, SOCK_DEAD)) { sk->sk_state_change(sk); ... } ... if (sk->sk_write_pending || icsk->icsk_accept_queue.rskq_defer_accept || icsk->icsk_ack.pingpong) { ... } else { tcp_send_ack(sk); } return -1; } ...}方法描述1. 如果此ack消息里没有syn标志,则丢弃消息。2. 调用tcp_finish_connect方法,将sk->sk_state设置为TCP_ESTABLISHED,表示tcp建立连接成功。 netipv4tcp_input.cvoid tcp_finish_connect(struct sock *sk, struct sk_buff *skb){ ... tcp_set_state(sk, TCP_ESTABLISHED); ...}3. 调用sk->sk_state_change方法,通知sock状态发生变化。在上一篇文章中我们讲到,如果socket没设置nonblock状态,则当connect时,会阻塞等待状态变化,而这里的sk->sk_state_change方法,正是用于告知等待线程sock状态变化了,可以从阻塞状态退出了。4. 调用tcp_send_ack方法发送三次握手的最终的ack消息。我们再来看下,服务端在收到这个ack消息后是如何处理的。还是看tcp_v4_rcv方法 netipv4tcp_ipv4.cint tcp_v4_rcv(struct sk_buff *skb){ ... const struct tcphdr *th; ...  struct sock *sk;  ... th = (const struct tcphdr *)skb->data; ... sk = __inet_lookup_skb(&tcp_hashinfo, skb, __tcp_hdrlen(th), th->source,             th->dest, sdif, &refcounted);  ... if (sk->sk_state == TCP_NEW_SYN_RECV) { struct request_sock *req = inet_reqsk(sk); struct sock *nsk;     sk = req->rsk_listener;    ... nsk = NULL;    if (!tcp_filter(sk, skb)) {     ... nsk = tcp_check_req(sk, skb, req, false);    }    ...    if (nsk == sk) {     ...    } else if (tcp_child_process(sk, nsk, skb)) {     ...    } else {     ... return 0; }  }  ...}方法描述1. 调用__inet_lookup_skb方法,根据ip、端口等信息找到对应的sock。2. 因为sk->sk_state为TCP_NEW_SYN_RECV,所以将sk转成struct request_sock类型,并赋值给req。3. 将sk值设置为req->rsk_listener,即listen sock。4. 调用tcp_check_req方法,创建一个新的struct sock实例newsk,把newsk->sk_state状态设置为TCP_SYN_RECV,之后把struct request_sock实例中的数据赋值到newsk中,再之后把newsk放到全局的hashtable中,最后把newsk放到listen sock的icsk_accept_queue队列中,这样后面的accept方法就能从这个队列获取这个sock了。由于涉及到的代码太多,这里就不贴代码了,只说下相关方法 netipv4tcp_ipv4.ctcp_v4_syn_recv_sock  netipv4inet_connection_sock.cinet_csk_complete_hashdance5. 调用tcp_child_process将nsk->sk_state设置为TCP_ESTABLISHED,表示连接建立成功。 netipv4tcp_minisocks.cint tcp_child_process(struct sock *parent, struct sock *child, struct sk_buff *skb){ int ret = 0; int state = child->sk_state; ... if (!sock_owned_by_user(child)) {    ret = tcp_rcv_state_process(child, skb);    ...  } else {   ...  }  ... return ret;}EXPORT_SYMBOL(tcp_child_process);该方法调用了tcp_rcv_state_process方法,此时参数child的sk_state为TCP_SYN_RECV。 netipv4tcp_input.cint tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb){  ... switch (sk->sk_state) { case TCP_SYN_RECV: ... tcp_set_state(sk, TCP_ESTABLISHED);    sk->sk_state_change(sk);    ...    break;  ... } ... return 0;}EXPORT_SYMBOL(tcp_rcv_state_process);6. return 0 给上层,表示成功。至此,tcp三次握手全部结束,tcp连接建立成功。完。
    来自:
    浏览:925
  • Kubernetes 1.14.2 HA Master NGINX负载均衡器log.go:172] http:来自192.168.5.32:43148的TLS握手错误:远程错误:tls:错误证书

    (11):* TLSv1.2 (IN), TLS handshake, Server key exchange (12):* TLSv1.2 (IN), TLS handshake, Requesthello (1):* TLSv1.2 (OUT), TLS handshake, Finished (20):* TLSv1.2 (IN), TLS handshake, Finished (20)(11):* TLSv1.2 (IN), TLS handshake, Server key exchange (12):* TLSv1.2 (IN), TLS handshake, Requesthello (1):* TLSv1.2 (OUT), TLS handshake, Finished (20):* TLSv1.2 (IN), TLS handshake, Finished (20)(11):* TLSv1.2 (IN), TLS handshake, Server key exchange (12):* TLSv1.2 (IN), TLS handshake, Request
    来自:
    回答:2
  • https的过程 (草稿)

    successfully set certificate verify locations:* CAfile: etcsslcert.pem CApath: none* TLSv1.2 (OUT), TLS handshake, Client hello (1):* TLSv1.2 (IN), TLS handshake, Server hello (2):* TLSv1.2 (IN), TLS handshake, Certificate(11):* TLSv1.2 (IN), TLS handshake, Server key exchange (12):* TLSv1.2 (IN), TLS handshake, Server finished(14):* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):* TLSv1.2 (OUT), TLS change cipher, Changecipher spec (1):* TLSv1.2 (OUT), TLS handshake, Finished (20):* TLSv1.2 (IN), TLS change cipher, Change
    来自:
    浏览:143
  • Netty websocket SSL连接HANDSHAKE_ISSUED?

    从netty编辑日志,需要更改xxx的附件: 03-29 17:10:01.294 27227-27604com.x.androidtestapp DnativeSSL: REGISTERED03-29 17:10:01.294 27227-27604com.x.androidtestapp DnativeSSL: CONNECT: xxxxxx03-29 17:10:01.594 27227-27604com.x.androidtestapp DnativeSSL: ACTIVE03-29 17:10:01.604 27227-27604com.x.androidtestapp DnativeSSL: WRITE, DefaultFullHttpRequest(decodeResult: success)03-29 17:10:01.604 27227-27604com.x.androidtestapp DnativeSSL: GET notificationnotificationChannelwebsocket HTTP1.103-29 17:10:01.604 27227-27604com.x.androidtestapp DnativeSSL: Upgrade: websocket03-29 17:10:01.604 27227-27604com.x.androidtestapp DnativeSSL: Connection: Upgrade03-29 17:10:01.604 27227-27604com.x.androidtestapp DnativeSSL: Sec-WebSocket-Key: K4zSElkfuBKi6ymQ1VVhuw==03-29 17:10:01.604 27227-27604com.x.androidtestapp DnativeSSL: Host: xxx03-29 17:10:01.604 27227-27604com.x.androidtestapp DnativeSSL: Sec-WebSocket-Origin: http:xxx03-29 17:10:01.604 27227-27604com.x.androidtestapp DnativeSSL: Sec-WebSocket-Version: 13, 0B03-29 17:10:01.604 27227-27604com.x.androidtestapp DnativeSSL: FLUSH03-29 17:10:02.575 27227-27604com.x.androidtestapp DnativeSSL: UNREGISTERED
    来自:
    回答:1
  • GPU 云服务器

    腾讯GPU 云服务器是提供 GPU 算力的弹性计算服务,具有超强的并行计算能力,作为 IaaS 层的尖兵利器,服务于深度学习训练、科学计算、图形图像处理、视频编解码等场景……
    来自:
  • FPGA 云服务器

    腾讯FPGA云服务器是基于FPGA硬件可编程加速的弹性计算服务,您只需几分钟就可以获取并部署您的FPGA实例。结合IP市场提供的图片,视频,基因等相关领域的计算解决方案,提供无与伦比的计算加速能力……
    来自:

扫码关注云+社区

领取腾讯云代金券