| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 12 Oct 2015 15:51:32 -0400 From: Sowmini Varadhan <sowmini.varadhan@...cle.com> To: netdev@...r.kernel.org, tom@...bertland.com Subject: a question about the kcm proposal Thinking back a bit about the kcm proposal: https://www.mail-archive.com/netdev@vger.kernel.org/msg78696.html I had a question: If the user-space has decided to encrypt the http/2 header using tls, the len (and other http/2 fields) is no longer in the clear for the kernel. My understanding is that http header encryption is common practice/BCP, since the http hdr may contain a lot of identity, session and tenancy data. If that's true, then wouldn't this break the BPF/kcm assumptions? There is a different but related problem in this space- existing TLS/DTLS libraries (openssl, gnutls etc) only know how to work with tcp or udp sockets - they do not know anything about PF_RDS or the newly proposed kcm socket type. In theory, it is possible to extend these libraries to handle RDS/kcm etc, but (as we found out with RDS and IP_PKTINFO/BINDTODEVICE), some things become tricky because of the many-to-one dgram-over-stream hybrid. I've looked at IPSEC/IKE in transport mode for RDS on the kernel tcp socket as we discussed at Plumbers in August, and that has some costs.. would be interesting to evaluate against other options.. --Sowmini -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists