TaLoS: library that integrates Intel SGX with OpenSSL

TaLoS: Efficient TLS Termination Inside SGX Enclaves for Existing Applications

TaLoS1 is a TLS library that allows existing applications (with an OpenSSL/LibreSSL interface) to securely terminate their TLS connection. For this, TaLoS places security-sensistive code and data of the TLS library inside an Intel SGX enclave, while the rest of the application remains outside. It can then be used as the building block for a wide range of security-critical applications for which the integrity and/or confidentiality of TLS connections must be guaranteed. TaLoS provides good performance by executing enclave transitions asynchronously and leveraging user-level threading inside the enclave. The code is accompanied with a technical report, containing details about the architecture and performance results. In contrast to the SSL add-on for the Intel SGX SDK, TaLoS exposes the OpenSSL/LibreSSL API to untrusted code outside of the enclave. This means that existing applications can use the TaLoS library with no or only minor modifications. The Intel SGX SDK SSL add-on does not expose an outside interface, which means that applications must be modified to use it.[…]

https://github.com/lsds/TaLoS

 

tlsfuzzer announced

Hubert Kario of Red Hat announced a new tool on the OSS-security list today. The tool, ‘tlsfuzzer’, is for reproducing, testing and (in the future) automatically finding issues in TLS implementations.

I’m looking forward to seeing if this can help test Tianocore’s HTTPS support, when TLS is added. 🙂

Click to access ruxcon2015-kario-slides.pdf

https://github.com/tomato42/tlsfuzzer

For more information, see the full post on the OSS-security list.

New UEFI HTTP Boot support in UEFI 2.5

One of the new features in UEFI 2.5 is the use of the HTTP protocol for network booting. Previously, UEFI booted remotely, using IPv4 or IPv6, starting with DHCP, then finishing using TFTP, “PXE-based”. This new UEFI 2.5 change defines new DHCP options to specify URI-based pointers to the “Network Boot Program (NBP)”, the binary image to download and run, which can be used using HTTP instead of TFTP. DHCP Servers will need to support this new HTTPBoot extension, if the DHCP type code for x86 is 0x0F and 0x10 for x64. For example, inside a corporate enterprise, with an URL like:
http://examplebootserver/boot/boot.efi

HTTP aside, the new spec hints of future URI-based network protocol support, such as FTP or NFS, in the future.

AFAICT, this presumes HTTP, not HTTPS. Most of the spec says HTTP. Only in one place did I see a reference to TLS and HTTPS, see Figure 72. But TLS and the S in HTTPS were in red, unlike all else, unclear what this means, if it is not public feature only in commercial UEFI products, etc.  Speak up if you know.

The spec mentions both enterprise and home use of this protocol, and they mention usage of this protocol across across networks (via the public Internet), not just internal home/corporate network use.

Refer to section 23.7 of the UEFI v2.5 specification for more details.
http://www.uefi.org/specsandtesttools

I’ve yet to locate this code in the public TianoCore EDK-II trunk; either I’ve missed it, it hasn’t yet been checked in, or the code is part of a non-open source codebase. It would answer the HTTPS/TLS question, as well. Speak up if you know the answer!

UEFI systems’s updates can incorporate new features, so this feature may show up in your system the next time your vendor issues an update. So, DNS, DHCP, and HTTP are all network attack vectors for network UEFI booting. Is your firewall/router ready for UEFI HTTP Booting?