From owner-freebsd-current@freebsd.org Mon Feb 3 22:49:41 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9084F2315A9 for ; Mon, 3 Feb 2020 22:49:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670084.outbound.protection.outlook.com [40.107.67.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48BNLX4lThz4Flm; Mon, 3 Feb 2020 22:49:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XRdznIriplFOwloJDx3JKzMwLMNPHEWCOpnlRKG/MHj+14c9XhgunhDNiQWkaAHGL3pdOnUPc6tx1qkjhDl9FdwHP80VmiVUAtFTMts67mBEay5X84Q9kcEaHZn/nzGdaUN5on+llOrrl5F03/W3PTYVPXz5q2R2eHcXWi4r8TJW0TAndkPHS8rMP0v37jCD41AaagYj1MeXMlgq4IU4f2D1I4rDIMoCTPRMALlOsqmKF0H6fpjvKl9v/Fg6RjLLQZKwoPRJ0e2qepF9TYNtsH0UiDPAacrYRbUtJwgpLI8pTOEPYa5eY3upDQR+5N5YP6bpQbBnVXgbkZE/XldNKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W/9/da1EHCsc1tyCsaGsRnMyzsK3qXHdOfkcBTdvA8g=; b=XOPoTFXI54ROBIw2o40rKm7AHZJxG+GQYArlIGOi5Ot24V1PVTT/djHT/+9KrPve7UUOwULUMcHgrEpSROVkilpbK0iqTQcYHrxIJ7jPeP5lp3KT2UBqYYZ38pkaT7zbkCeFaNUhfUfPXBNPJyHiHOf28eChkUa3TU3jTbkMtnrw91tlpX+6sHWmcxIZ4/nVRDTElUgb42BD8FitXmNpqqwQCmRQPlRR9kF3BO2YqXynPrVd4XbBxTIzpN+HUn0IUTttl3AtDkZRyZvTHHOeIGUJy98ZREcGf+KFRC4O9gVSe+8x5fDBrdMmfMCv4W3AS8bNxm508XQla30FtLgUpg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM (10.255.46.82) by YTBPR01MB3520.CANPRD01.PROD.OUTLOOK.COM (10.255.47.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.29; Mon, 3 Feb 2020 22:49:39 +0000 Received: from YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM ([fe80::410e:652b:6fbc:9aa4]) by YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM ([fe80::410e:652b:6fbc:9aa4%3]) with mapi id 15.20.2686.031; Mon, 3 Feb 2020 22:49:39 +0000 From: Rick Macklem To: Benjamin Kaduk CC: John Baldwin , "freebsd-current@FreeBSD.org" Subject: Re: how to use the ktls Thread-Topic: how to use the ktls Thread-Index: AQHVxa2HeRfmo36hWEyrGcMaBhE88KfhEeoAgBxnlpmAAOgvAIACbdpNgAOAJ4CABeuelw== Date: Mon, 3 Feb 2020 22:49:38 +0000 Message-ID: References: <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> , <20200131041843.GC24@kduck.mit.edu> In-Reply-To: <20200131041843.GC24@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8cb5a793-143d-40bc-4f94-08d7a8fb59a1 x-ms-traffictypediagnostic: YTBPR01MB3520: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0302D4F392 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(376002)(396003)(39860400002)(346002)(199004)(189003)(4326008)(54906003)(7696005)(786003)(26005)(6506007)(316002)(71200400001)(86362001)(6916009)(478600001)(52536014)(8676002)(33656002)(81156014)(8936002)(2906002)(81166006)(66476007)(64756008)(55016002)(66946007)(186003)(76116006)(91956017)(9686003)(66446008)(66556008)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTBPR01MB3520; H:YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KbNJg//Yth9BZLLSjOWHsAZQ3jQBIzJGs0w7Ar+LtpbB10QPgVPU4cmHR4VhSogXqq6VkxHuK3/ZBBlf+hHq6Xxk1/yfpTwWK4lbuJOl/79Y6k9bs/MZ+lBsacdjQz026EilJs2tFjUpqck6ukfWs11uQMAGyCW31GrFstuFE/Q0gEbE8PFLLZCU4SqlSQ5sdG/UrzNtCSc0ARvoL79o4dtYo1BEeYiUyV9/20+wNMr+sVMKql7702EqeGMFGpzP3YGNjGckECR5DWXlBI23Jgmf3i9NT7seG6QWfLDTFG8zOESKiTC7++nFGHF7r+mVgqqI6J+czUQfPB5lOCMumVrmY5P0kXV9oTtMscm5wqUuWIl3vztIQXNcPNjWXhqc0WgLxSbucrV6Bi5npnyiXVfron7HR4J0GfFbw14QQ6WbewEJMEKsMTQAAwlADsub x-ms-exchange-antispam-messagedata: nbjQqBOfdEhA9N4KpG/FpBe13l6doGKPMAaJulcS+YBHnBRcOsUiLH5jPUC9h1DUj+y7xP5I6GwUxfnEzA4DnWlrRS8mzeKsECAkclYKFzGiIMH9Ze4BEJLzG1+q3HSTPxBODEly9hPRO8nCiZLfgA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 8cb5a793-143d-40bc-4f94-08d7a8fb59a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2020 22:49:38.9366 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VdMwogGYMC4sMhrTsCg4KGgTvC/yMhIwEZN/YbzoY52GrGCbMXwrvNolOohzND/l2mfLcVrdBwy+K9FgT7LCiQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3520 X-Rspamd-Queue-Id: 48BNLX4lThz4Flm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.84 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.70 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[uoguelph.ca]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[84.67.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-1.40)[ipnet: 40.64.0.0/10(-3.86), asn: 8075(-3.07), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 22:49:41 -0000 Benjamin Kaduk wrote:=0A= >On Tue, Jan 28, 2020 at 11:01:31PM +0000, Rick Macklem wrote:=0A= >> John Baldwin wrote:=0A= >> [stuff snipped]=0A= >> >I don't know yet. :-/ With the TOE-based TLS I had been testing with, = this doesn't=0A= >> >happen because the NIC blocks the data until it gets the key and then i= t's always=0A= >> >available via KTLS. With software-based KTLS for RX (which I'm going t= o start=0A= >> >working on soon), this won't be the case and you will potentially have = some data=0A= >> >already ready by OpenSSL that needs to be drained from OpenSSL before y= ou can=0A= >> >depend on KTLS. It's probably only the first few messsages, but I will= need to figure=0A= >> >out a way that you can tell how much pending data in userland you need = to read via=0A= >> >SSL_read() and then pass back into the kernel before relying on KTLS (i= t would just=0A= >> >be a single chunk of data after SSL_connect you would have to do this f= or).=0A= >> I think SSL_read() ends up calling ssl3_read_bytes(..APPLICATION..) and = then it throws=0A= >> away non-application data records. (Not sure, ssl3_read_bytes() gets pre= tty convoluted at=0A= >> a glance.;-)=0A= >=0A= >Yes, SSL_read() interprets the TLS record type and only passes application= =0A= >data records through to the application. It doesn't exactly "throw away"= =0A= >the other records, though -- they still get processed, just internally to= =0A= >libssl :)=0A= >I expect based on heuristics that the 485 bytes are a NewSessionTicket=0A= >message, but that actual length is very much not a protocol constant and i= s=0A= >an implementation detail of the TLS server. (That said, an openssl server= =0A= >is going to be producing the same length every time, for a given version o= f=0A= >openssl, unless you configure it otherwise.)=0A= Well, I looked at the data and it appears to be two application data record= s,=0A= both of length 234. (These are in the receive queue before the other end do= es=0A= an SSL_write() and the only data returned by SSL_read() is what a subsequen= t=0A= SSL_write() has written.)=0A= =0A= My hunch is that, once they are unencrypted, they are just padding.=0A= Anyhow, since they are "application data" the receive side of KERN_TLS=0A= should be able to handle them.=0A= --> I don't think I need to do anything after the SSL_connect() in userland= =0A= to deal with these.=0A= =0A= Thanks for your help, rick=0A= =0A= -Ben=0A=