TLS-N: Non-repudiation over TLS Enabling Ubiquitous Content Signing
Hubert Ritzdorf, Karl Wüst, Arthur Gervais, Guillaume Felley, Srđjan Čapkun · 2018
An internet user wanting to share observed content is typically restricted to primitive techniques such as screenshots, web caches or share button-like solutions.These acclaimed proofs, however, are either trivial to falsify or require trust in centralized entities (e.g., search engine caches).This motivates the need for a seamless and standardized internet-wide non-repudiation mechanism, allowing users to share data from news sources, social websites or financial data feeds in a provably secure manner.Additionally, blockchain oracles that enable data-rich smart contracts typically rely on a trusted third party (e.g., TLSNotary or Intel SGX).A decentralized method to transfer webbased content into a permissionless blockchain without additional trusted third party would allow for smart contract applications to flourish.In this work, we present TLS-N, the first TLS extension that provides secure non-repudiation and solves both of the mentioned challenges.TLS-N generates non-interactive proofs about the content of a TLS session that can be efficiently verified by third parties and blockchain based smart contracts.As such, TLS-N increases the accountability for content provided on the web and enables a practical and decentralized blockchain oracle for web content.TLS-N is compatible with TLS 1.3 and adds a minor overhead to a typical TLS session.When a proof is generated, parts of the TLS session (e.g., passwords, cookies) can be hidden for privacy reasons, while the remaining content can be verified.authentication of additional key material, thereby significantly increasing the complexity of the solution.In TLS-N, by the definition of non-repudiation, message authentication and the identification of at least one TLS peer is guaranteed.We compare TLS-N to existing non-repudiation proposals and identify properties that non-repudiation solutions must possess for particular use cases.We implement and evaluate TLS-N as an extension of the new TLS 1.3 standard.As such, we implement a TLS-N-enabled web server, web client, an Ethereum-based library for proof parsing and verification and finally an Ethereumbased oracle that uses TLS-N proofs.We also deploy the oracle inside the public Ethereum test network.The implementation details, the code and contract addresses can be found at https://tls-n.org, which itself has TLS-N enabled.Furthermore, users can use the website to generate and verify TLS-N proofs.We find that our prototype implementation incurs an overhead of less than 1.5 milliseconds on existing TLS connections per HTTP request for responses of 10 KB or less, which is a realistic size for an API response.Verifying our proof examples in a smart contract costs between 0.5 and 8 USD due to the currently high gas price 1 .Prices depend on the proof size and signature type.Note that, once this proof is verified, it can be used by millions of blockchain users.As a summary our contributions are as follows:• We propose the first secure non-repudiation solution that captures privacy and performance requirements and can be seamlessly integrated with the TLS 1.3 standard [39].Our solution does not add new security assumptions to those of TLS and does not rely on an additional trusted third party.• We implement our extension for TLS 1.3 on top of Mozilla's NSS library [33] and create an Apache module supporting our extension.Our experimental evaluation shows that a typical proof size as well as the proof generation and verification times grow linear with the size of the data.The server side processing times are low with less than 1ms for 16 KB plaintext without privacy protection and less than 8ms for 16 KB plaintext with privacy protection.• We provide an Ethereum-based library for TLS-N proof verification and parsing.TLS-N therefore acts as a practical decentralized blockchain oracle that does not require any additional trusted third party.Users can source data from any TLS-N-enabled content provider, submit it to the blockchain where the smart contract verifies the proof.Note that only the data provider needs to be trusted, and as such any client can submit a TLS-N proof to the smart contract.On our website, https://tls-n.orgwe also provide an example oracle that securely inserts bitcoin prices into the Ethereum blockchain based on an API from bitcoin.com.• We provide a structured description of non-repudiation properties, possible attacks, requirements and usecases for non-repudiation solutions.