DOCSLIB.ORG

Gluon Documentation Release 2021.1.1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Gluon Documentation Release 2021.1.1 Gluon Documentation Release 2021.1.1 Project Gluon Aug 14, 2021 User Documentation 1 Getting Started 3 1.1 Selecting the right version........................................3 1.2 Dependencies...............................................3 1.3 Building the images...........................................4 1.4 opkg repositories.............................................5 1.5 Make variables..............................................6 2 Site configuration 9 2.1 Configuration...............................................9 2.2 Build configuration............................................ 17 2.3 Config mode texts............................................ 18 2.4 Site modules............................................... 19 2.5 Examples................................................. 19 3 Supported Devices & Architectures 31 3.1 ar71xx-generic.............................................. 31 3.2 ar71xx-nand............................................... 34 3.3 ar71xx-tiny............................................... 34 3.4 ath79-generic............................................... 35 3.5 brcm2708-bcm2708........................................... 36 3.6 brcm2708-bcm2709........................................... 36 3.7 ipq40xx-generic............................................. 36 3.8 ipq806x-generic............................................. 37 3.9 lantiq-xrx200............................................... 37 3.10 lantiq-xway................................................ 37 3.11 mpc85xx-generic............................................. 37 3.12 mpc85xx-p1020............................................. 37 3.13 ramips-mt7620.............................................. 38 3.14 ramips-mt7621.............................................. 38 3.15 ramips-mt76x8.............................................. 39 3.16 ramips-rt305x.............................................. 39 3.17 sunxi-cortexa7.............................................. 39 3.18 x86-generic................................................ 40 3.19 x86-geode................................................ 40 3.20 x86-64.................................................. 40 3.21 Footnotes................................................. 40 i 4 x86 support 41 4.1 Targets.................................................. 41 5 Frequently Asked Questions 43 5.1 What hardware is supported?...................................... 43 5.2 Why does DNS not work on the nodes?................................. 43 5.3 What is a good MTU on the mesh-vpn?................................. 43 6 Config Mode 47 6.1 Activating Config Mode......................................... 47 6.2 Port Configuration............................................ 47 6.3 Accessing Config Mode......................................... 47 7 Autoupdater 49 7.1 Building Images............................................. 49 7.2 Manifest format............................................. 49 7.3 Automated nightly builds........................................ 50 7.4 Infrastructure............................................... 50 7.5 Command Line.............................................. 50 8 WLAN configuration 53 8.1 Upgrade behaviour............................................ 53 9 Private WLAN 55 10 Wired mesh (Mesh-on-WAN/LAN) 57 10.1 Wired mesh encapsulation........................................ 57 10.2 Configuration............................................... 58 11 DNS forwarder 59 12 Node monitoring 61 12.1 Format of collected data......................................... 61 12.2 Accessing Node Information....................................... 61 12.3 Adding a data provider.......................................... 63 13 Multidomain Support 65 13.1 Preamble................................................. 65 13.2 Overview................................................. 65 13.3 Switching the domain.......................................... 66 13.4 Allowed site variables.......................................... 67 13.5 Example config.............................................. 69 14 Adding SSH public keys 79 15 Roles 81 16 Mesh-VPN 83 16.1 fastd................................................... 83 17 Development Basics 85 17.1 Bug Tracker............................................... 85 17.2 IRC.................................................... 85 17.3 Working with repositories........................................ 85 17.4 Development Guidelines......................................... 86 ii 18 Adding support for new hardware 87 18.1 Hardware requirements......................................... 87 18.2 Device checklist............................................. 87 18.3 Device classes.............................................. 87 18.4 Adding profiles.............................................. 88 18.5 Adding support for new hardware targets................................ 89 19 Package development 91 19.1 Gluon package makefiles......................................... 91 19.2 Feature flags............................................... 92 20 Upgrade scripts 95 20.1 Basics................................................... 95 20.2 Best practices............................................... 95 20.3 Script ordering.............................................. 95 21 WAN support 97 21.1 Routing tables.............................................. 97 21.2 libpacketmark.............................................. 97 21.3 gluon-wan-dnsmasq........................................... 98 22 MAC addresses 99 23 gluon.site library 101 24 Build system 103 24.1 Feed management............................................ 103 24.2 Helper scripts............................................... 103 25 Debugging 105 25.1 Kernel Oops............................................... 105 26 Controllers 107 26.1 Dispatchers................................................ 107 26.2 The HTTP object............................................. 108 26.3 The template renderer.......................................... 108 26.4 Differences from LuCI.......................................... 108 27 Models 111 27.1 Classes and methods........................................... 112 27.2 Data types................................................ 113 27.3 Differences from LuCI.......................................... 113 28 Views 115 28.1 Variables and functions.......................................... 116 29 Internationalization support 117 29.1 General guidelines............................................ 117 29.2 i18n support in Gluon.......................................... 117 29.3 Adding translation templates to Gluon packages............................ 118 29.4 Adding translations............................................ 118 29.5 Adding support for new languages.................................... 119 30 Config Mode 121 30.1 Writing Config Mode modules...................................... 121 iii 31 gluon-client-bridge 123 31.1 site.conf................................................. 123 32 gluon-config-mode-domain-select 125 32.1 domains/*.conf.............................................. 125 33 gluon-ebtables-filter-multicast 127 34 gluon-ebtables-filter-ra-dhcp 129 35 gluon-ebtables-limit-arp 131 36 gluon-ebtables-source-filter 133 36.1 site.conf................................................. 133 37 gluon-hoodselector 135 37.1 Background information......................................... 135 37.2 Behaviour................................................. 135 37.3 Domain shapes.............................................. 137 37.4 site.conf................................................. 137 38 gluon-logging 139 38.1 site.conf................................................. 139 39 gluon-mesh-batman-adv 141 39.1 B.A.T.M.A.N. Routing Algorithms................................... 141 39.2 Node-Local Multicast Handling..................................... 142 39.3 Mesh-wide Multicast Handling..................................... 142 39.4 IGMP/MLD Domain Segmentation................................... 143 40 gluon-mesh-wireless-sae 145 40.1 site.conf................................................. 145 41 gluon-radv-filterd 147 41.1 Selected router.............................................. 147 41.2 Local routers............................................... 147 41.3 respondd module............................................. 148 41.4 site.conf................................................. 148 42 gluon-scheduled-domain-switch 149 42.1 site.conf................................................. 149 43 gluon-web-admin 151 43.1 site.conf................................................. 151 44 gluon-web-logging 153 45 Gluon 2021.1.1 155 45.1 Important notes.............................................. 155 45.2 Added hardware support......................................... 155 45.3 Bugfixes................................................. 155 45.4 Known issues............................................... 156 46 Gluon 2021.1 157 46.1 Important notes.............................................. 157 46.2 Added hardware support......................................... 157 iv 46.3 Major changes.............................................. 158 46.4 Other changes.............................................. 158 46.5 Bugfixes................................................. 159 46.6 Internal.................................................. 159 46.7 Known issues............................................... 159 47 Gluon 2020.2.3 161 47.1 Bugfixes................................................
Load more

Recommended publications
  • Opportunistic Keying As a Countermeasure to Pervasive Monitoring
    Opportunistic Keying as a Countermeasure to Pervasive Monitoring Stephen Kent BBN Technologies Abstract This document was prepared as part of the IETF response to concerns about “pervasive monitoring” (PM) [Farrell-pm]. It begins by exploring terminology that has been used in IETF standards (and in academic publications) to describe encryption and key management techniques, with a focus on authentication and anonymity. Based on this analysis, it propose a new term, “opportunistic keying” to describe a goal for IETF security protocols, in response to PM. It reviews key management mechanisms used in IETF security protocol standards, also with respect to these properties. The document explores possible impediments to and potential adverse effects associated with deployment and use of techniques that would increase the use of encryption, even when keys are distributed in an unauthenticated manner. 1. What’s in a Name (for Encryption)? Recent discussions in the IETF about pervasive monitoring (PM) have suggested a desire to increase use of encryption, even when the encrypted communication is unauthenticated. The term “opportunistic encryption” has been suggested as a term to describe key management techniques in which authenticated encryption is the preferred outcome, unauthenticated encryption is an acceptable fallback, and plaintext (unencrypted) communication is an undesirable (but perhaps necessary) result. This mode of operation differs from the options commonly offered by many IETF security protocols, in which authenticated, encrypted communication is the desired outcome, but plaintext communication is the fallback. The term opportunistic encryption (OE) was coined by Michael Richardson in “Opportunistic Encryption using the Internet Key Exchange (IKE)” an Informational RFC [RFC4322].
    [Show full text]
  • Software-Defined Networking: Improving Security for Enterprise and Home Networks
    Worcester Polytechnic Institute Digital WPI Doctoral Dissertations (All Dissertations, All Years) Electronic Theses and Dissertations 2017-04-24 Software-defined etN working: Improving Security for Enterprise and Home Networks Curtis Robin Taylor Worcester Polytechnic Institute Follow this and additional works at: https://digitalcommons.wpi.edu/etd-dissertations Repository Citation Taylor, C. R. (2017). Software-defined Networking: Improving Security for Enterprise and Home Networks. Retrieved from https://digitalcommons.wpi.edu/etd-dissertations/161 This dissertation is brought to you for free and open access by Digital WPI. It has been accepted for inclusion in Doctoral Dissertations (All Dissertations, All Years) by an authorized administrator of Digital WPI. For more information, please contact [email protected]. Software-defined Networking: Improving Security for Enterprise and Home Networks by Curtis R. Taylor A Dissertation Submitted to the Faculty of the WORCESTER POLYTECHNIC INSTITUTE In partial fulfillment of the requirements for the Degree of Doctor of Philosophy in Computer Science by May 2017 APPROVED: Professor Craig A. Shue, Dissertation Advisor Professor Craig E. Wills, Head of Department Professor Mark Claypool, Committee Member Professor Thomas Eisenbarth, Committee Member Doctor Nathanael Paul, External Committee Member Abstract In enterprise networks, all aspects of the network, such as placement of security devices and performance, must be carefully considered. Even with forethought, networks operators are ulti- mately unaware of intra-subnet traffic. The inability to monitor intra-subnet traffic leads to blind spots in the network where compromised hosts have unfettered access to the network for spreading and reconnaissance. While network security middleboxes help to address compromises, they are limited in only seeing a subset of all network traffic that traverses routed infrastructure, which is where middleboxes are frequently deployed.
    [Show full text]
  • How Can We Protect the Internet Against Surveillance?
    How can we protect the Internet against surveillance? Seven TODO items for users, web developers and protocol engineers Peter Eckersley [email protected] Okay, so everyone is spying on the Internet It's not just the NSA... Lots of governments are in this game! Not to mention the commerical malware industry These guys are fearsome, octopus-like adversaries Does this mean we should just give up? No. Reason 1: some people can't afford to give up Reason 2: there is a line we can hold vs. So, how do we get there? TODO #1 Users should maximise their own security Make sure your OS and browser are patched! Use encryption where you can! In your browser, install HTTPS Everywhere https://eff.org/https-everywhere For instant messaging, use OTR (easiest with Pidgin or Adium, but be aware of the exploit risk tradeoff) For confidential browsing, use the Tor Browser Bundle Other tools to consider: TextSecure for SMS PGP for email (UX is terrible!) SpiderOak etc for cloud storage Lots of new things in the pipeline TODO #2 Run an open wireless network! openwireless.org How to do this securely right now? Chain your WPA2 network on a router below your open one. TODO #3 Site operators... Deploy SSL/TLS/HTTPS DEPLOY IT CORRECTLY! This, miserably, is a lot harder than it should be TLS/SSL Authentication Apparently, ~52 countries These are usually specialist, narrowly targetted attacks (but that's several entire other talks... we're working on making HTTPS more secure, easier and saner!) In the mean time, here's what you need A valid certificate HTTPS by default Secure cookies No “mixed content” Perfect Forward Secrecy A well-tuned configuration How do I make HTTPS the default? Firefox and Chrome: redirect, set the HSTS header Safari and IE: sorry, you can't (!!!) What's a secure cookie? Go and check your site right now..
    [Show full text]
  • The Danger of the New Internet Choke Points
    The Danger of the New Internet Choke Points Authored by: Andrei Robachevsky, Christine Runnegar, Karen O’Donoghue and Mat Ford FEBRUARY 2014 Introduction The ongoing disclosures of pervasive surveillance of Internet users’ communications and data by national security agencies have prompted protocol designers, software and hardware vendors, as well as Internet service and content providers, to re-evaluate prevailing security and privacy threat models and to refocus on providing more effective security and confidentiality. At IETF88, there was consensus to address pervasive monitoring as an attack and to consider the pervasive attack threat model when designing a protocol. One area of work currently being pursued by the IETF is the viability of more widespread encryption. While there are some who believe that widely deployed encryption with strong authentication should be used extensively, many others believe that there are practical obstacles to this approach including a general lack of reasonable tools and user understanding as to how to use the technology, plus significant obstacles to scaling infrastructure and services using existing technologies. As a result, the discussion within the IETF has principally focused on opportunistic encryption and weak authentication. “Weak authentication” means cryptographically strong authentication between previously unknown parties without relying on trusted third parties. In certain contexts, and by using certain techniques, one can achieve the desired level of security (see, for instance, Arkko, Nikander. Weak Authentication: How to Authenticate Unknown Principals without Trusted Parties, Security Protocols Workshop, volume 2845 of Lecture Notes in Computer Science, page 5-19. Springer, (2002)). “Opportunistic encryption” refers to encryption without authentication. It is a mode of protocol operation where the content of the communication is secure against passive surveillance, but there is no guarantee that the endpoints are reliably identified.
    [Show full text]
  • Applied Crypto Hardening
    Applied Crypto Hardening Wolfgang Breyha, David Durvaux, Tobias Dussa, L. Aaron Kaplan, Florian Mendel, Christian Mock, Manuel Koschuch, Adi Kriegisch, Ulrich Pöschl, Ramin Sabet, Berg San, Ralf Schlatterbeck, Thomas Schreck, Alexander Würstlein, Aaron Zauner, Pepi Zawodsky (University of Vienna, CERT.be, KIT-CERT, CERT.at, A-SIT/IAIK, coretec.at,FH Campus Wien, VRVis, MilCERT Austria, A-Trust, Runtux.com,Friedrich-Alexander University Erlangen-Nuremberg, azet.org, maclemon.at) April 25, 2017 Contents 1. Abstract 5 1.1. Acknowledgements ........................................ 6 2. Introduction 8 2.1. Audience .............................................. 8 2.2. Related publications ........................................ 8 2.3. How to read this guide ....................................... 8 2.4. Disclaimer and scope ........................................ 9 2.4.1. Scope ............................................ 10 2.5. Methods ............................................... 11 3. Practical recommendations 12 3.1. Webservers ............................................. 12 3.1.1. Apache ........................................... 12 3.1.2. lighttpd ........................................... 13 3.1.3. nginx ............................................ 14 3.1.4. Cherokee .......................................... 15 3.1.5. MS IIS ............................................ 17 3.2. SSH ................................................. 20 3.2.1. OpenSSH .......................................... 20 3.2.2. Cisco ASA .........................................
    [Show full text]
  • M 3 AAWG Describes Costs Associated with Using Crypto
    Messaging, Malware and Mobile Anti-Abuse Working Group M3AAWG Describes Costs Associated with Using Crypto March 2017 The reference URL for this document: www.m3aawg.org/Crypto-Costs I. Introduction Deploying opportunistic encryption as described in TLS for Mail: M3AAWG Initial Recommendations is an excellent way to start protecting email traffic between providers. Using Forward Secrecy to Secure Data is a further step providers can take. Forward secrecy ensures that encrypted traffic can never be decrypted, even if the relevant private keys are somehow eventually obtained. However, most everything, including cryptographic secrecy and privacy, comes at a cost. This document describes the budget and other costs associated with using cryptography to help the reader make an informed decision about what to do, or not do, when faced with the need to deploy encryption. II. When Needed, Content based Spam and Malware Filtering Should Be Done On-System, Not Passively On-Network Links While encryption protects against unwanted eavesdropping or tampering, it also precludes passive network monitoring1 for beneficial purposes, such as blocking spam or filtering malware. Traffic inspection is still possible; however, it just needs to be done on the endpoints before the traffic gets encrypted or after the traffic gets decrypted. In thinking about opportunities to do traffic inspection, it is important to distinguish between two cases: 1. Hop-by Hop Encryption In the hop-by-hop encryption case (for example, opportunistic SSL/TLS for SMTP2), traffic is encrypted and then decrypted for each hop (e.g., each link in the delivery chain). As a result, there are opportunities for filtering, and unfortunately, for eavesdropping or tampering at each intervening node.
    [Show full text]
  • Applied Crypto Hardening
    DrAFT REvision: ea089c8 (2014-01-11 22:11:44 +0100) AarON Kaplan Applied Crypto HarDENING WOLFGANG BrEyha, David Durvaux, TOBIAS Dussa, L. AarON Kaplan, Florian Mendel, Christian Mock, Manuel Koschuch, Adi Kriegisch, Ulrich Pöschl, Ramin Sabet, BerG San, Ralf Schlatterbeck, Thomas Schreck, AarON Zauner, Pepi Zawodsky (University OF Vienna, CERT.be, KIT-CERT, CERT.at, A-SIT/IAIK, CORetec.at, FH Campus Wien, VRVis, MilCERT Austria, A-Trust, Runtux.com, Friedrich-AleXANDER University Erlangen-NurEMBERg, azet.org, maclemon.at) January 13, 2014 DrAFT REvision: ea089c8 (2014-01-11 22:11:44 +0100) AarON Kaplan DrAFT REvision: ea089c8 (2014-01-11 22:11:44 +0100) AarON Kaplan Do NOT TALK UNENCRYPTED Applied Crypto HarDENING • DrAFT REvision: ea089c8 (2014-01-11 22:11:44 +0100) AarON Kaplan PAGE 2 OF 81 DrAFT REvision: ea089c8 (2014-01-11 22:11:44 +0100) AarON Kaplan DrAFT REvision: ea089c8 (2014-01-11 22:11:44 +0100) AarON Kaplan AcknoWLEDGEMENTS WE WOULD LIKE TO EXPRESS OUR THANKS TO THE FOLLOWING REVIEWERS AND PEOPLE WHO HAVE GENEROUSLY OffERED THEIR TIME AND INTEREST (in ALPHABETICAL ORder): BrOwn, Scott Millauer, TOBIAS Brulebois, Cyril O’Brien, Hugh Dirksen-Thedens, Mathis Pacher, Christoph DulaunoY, AleXANDRE Palfrader, Peter Gühring Philipp Pape, TOBIAS (layout) Grigg, IAN Petukhova, Anna (Logo) Horenbeck, Maarten Pichler, Patrick Huebl, AxEL Roeckx, Kurt Kovacic, Daniel Seidl, Eva (PDF layout) Lenzhofer, Stefan Wagner, Sebastian (“SEBIX”) Lorünser, Thomas Zangerl, AleXANDER The REVIEWERS DID REVIEW PARTS OF THE DOCUMENT IN THEIR AREA OF Expertise; ALL REMAINING ERRORS IN THIS DOCUMENT ARE THE SOLE RESPONSIBILITY OF THE PRIMARY authors. Applied Crypto HarDENING • DrAFT REvision: ea089c8 (2014-01-11 22:11:44 +0100) AarON Kaplan PAGE 3 OF 81 DrAFT REvision: ea089c8 (2014-01-11 22:11:44 +0100) AarON Kaplan DrAFT REvision: ea089c8 (2014-01-11 22:11:44 +0100) AarON Kaplan AbstrACT “Unfortunately, THE COMPUTER SECURITY AND CRYPTOLOGY COMMUNITIES HAVE DRIFTED APART OVER THE LAST 25 years.
    [Show full text]
  • Pervasive Internet-Wide Low-Latency Authentication
    Pervasive Internet-Wide Low-Latency Authentication Cyrill Krahenb¨ uhl¨ ∗, Markus Legnery, Silvan Bitterliz, and Adrian Perrigx Department of Computer Science, ETH Zurich, Switzerland Email: ∗[email protected], [email protected], [email protected], [email protected] Abstract—In a world with increasing simplicity to store, than client–server communication, such as peer-to-peer com- transfer, and analyze large volumes of data, it becomes more munication, or cases where setting up DNS entries for all and more important that data confidentiality and integrity be devices is infeasible, such as Internet-of-Things (IoT) settings. preserved in transit by default. Unfortunately, a large security gap exists between unprotected or low-security communication, Additionally, DNS resolvers, SSH servers, and IoT devices are such as opportunistic encryption and trust-on-first-use (TOFU) often identified by their IP address which precludes domain- security, and high-security communication, such as TLS using based authentication. server certificates or DNSSEC. Our goal is to reduce this gap We propose pervasive Internet-wide low-latency and achieve a base layer for authentication and secrecy that is authentication (PILA), a system to reduce the gap between strictly better than TOFU security. We achieve this by designing PILA, a novel authentication method with dynamic trust anchors, TOFU security and strong authentication mechanisms (Web which leverages irrefutable cryptographic proof of misbehavior to PKI and DANE). The goal is to create a mechanism that is incentivize benign behavior. We implement PILA extensions for orthogonal to existing strong authentication mechanisms and SSH, TLS, and DNS and show that the overhead for a typical not to replace them.
    [Show full text]
  • Applied Crypto Hardening
    Applied Crypto HarDENING WOLFGANG BrEyha, David Durvaux, TOBIAS Dussa, L. AarON Kaplan, Florian Mendel, Christian Mock, Manuel Koschuch, Adi Kriegisch, Ulrich Pöschl, Ramin Sabet, BerG San, Ralf Schlatterbeck, Thomas Schreck, AleXANDER Würstlein, AarON Zauner, Pepi Zawodsky (University OF Vienna, CERT.be, KIT-CERT, CERT.at, A-SIT/IAIK, CORetec.at, FH Campus Wien, VRVis, MilCERT Austria, A-Trust, Runtux.com, Friedrich-AleXANDER University Erlangen-NurEMBERg, azet.org, maclemon.at) NoVEMBER 10, 2016 Do NOT TALK UNENCRYPTED Applied Crypto HarDENING PAGE 2 OF 111 AcknoWLEDGEMENTS WE WOULD LIKE TO EXPRESS OUR THANKS TO THE FOLLOWING REVIEWERS AND PEOPLE WHO HAVE GENEROUSLY OffERED THEIR TIME AND INTEREST (in ALPHABETICAL ORder): BrOwn, Scott Pacher, Christoph Brulebois, Cyril Palfrader, Peter Dirksen-Thedens, Mathis Pape, TOBIAS (layout) DulaunoY, AleXANDRE Petukhova, Anna (Logo) Gühring Philipp Pichler, Patrick Grigg, IAN Riebesel, Nicolas Haslinger, Gunnar Roeckx, Kurt Huebl, AxEL Roesen, Jens Kovacic, Daniel Rublik, Martin Lenzhofer, Stefan Schüpany, Mathias Lorünser, Thomas Schwarz, René («DigNative») Maass, Max Seidl, Eva (PDF layout) Mehlmauer, Christian VAN Horenbeeck, Maarten Millauer, TOBIAS Wagner, Sebastian («sebix») Mirbach, AndrEAS Zangerl, AleXANDER O’Brien, Hugh The REVIEWERS DID REVIEW PARTS OF THE DOCUMENT IN THEIR AREA OF Expertise; ALL REMAINING ERRORS IN THIS DOCUMENT ARE THE SOLE RESPONSIBILITY OF THE PRIMARY authors. Applied Crypto HarDENING PAGE 3 OF 111 AbstrACT “Unfortunately, THE COMPUTER SECURITY AND CRYPTOLOGY COMMUNITIES HAVE DRIFTED APART OVER THE LAST 25 years. Security PEOPLE DON’T ALWAYS UNDERSTAND THE AVAILABLE CRYPTO tools, AND CRYPTO PEOPLE DON’T ALWAYS UNDERSTAND THE Real-world PRoblems.” — Ross Anderson IN [And08] This GUIDE AROSE OUT OF THE NEED FOR SYSTEM ADMINISTRATORS TO HAVE AN updated, solid, WELL Re- SEARCHED AND thought-thrOUGH GUIDE FOR CONfiGURING SSL, PGP, SSH AND OTHER CRYPTOGRAPHIC TOOLS IN THE post-SnoWDEN age.
    [Show full text]
  • SSL & TLS Story of a Protocol Part II
    Introduction to Information Security SSL & TLS Story of a protocol Part II Itamar Gilad (infosec15 at modprobe dot net) Certificate examples • Good example Certificate examples • Good example Certificate examples • Not-so-good example Certificate examples • Not-so-good example Reflecting trust to users • We want users to know if a site is “safe” or not • There are many things that may cause a certificate to be rejected o Too old / too new (also caused by mis-configured dates on the host) o Misconfigured servers (e.g.: presenting the wrong certificate for a subdomain) o Client & server cannot agree on a cipher o Self-signed or untrusted certificate, but not a malicious attack o Actual attack • In reality, attacks are rare • Nonetheless, we must be strict – reject and prompt the user! • Result – few sites will even use SSL/TLS • HTTP is more common than HTTPS by far (and often, users will connect to the HTTP version of an HTTPS website anyway…) Other reasons HTTPS is not as common as HTTP • Performance issues – o though negligible for the client, a server has to perform many costly operations to support many clients (in particular – public key operations). Solution – Crypto accelerators & better support in modern CPUs • Harder to obtain, configure & maintain – o More complex & often costly than plain HTTP • Bad threat model – o Many companies & organizations do not see themselves or their users as a target, so “there’s no need for encryption” • Internet caching / filtering – o ISPs cannot cache (or otherwise inspect, manipulate or block)
    [Show full text]
  • The Case for Ubiquitous Transport-Level Encryption
    The case for ubiquitous transport-level encryption Andrea Bittau Michael Hamburg Mark Handley David Mazieres` Dan Boneh Stanford Stanford UCL Stanford Stanford Abstract • Encryption (and key bootstrap) are too expensive to perform for all but critical traffic. Today, Internet traffic is encrypted only when deemed necessary. Yet modern CPUs could feasibly encrypt most • The standard protocol solutions are a poor match for traffic. Moreover, the cost of doing so will only drop the problem. over time. Tcpcrypt is a TCP extension designed to make We believe that each of these points either is not true, end-to-end encryption of TCP traffic the default, not the or can be directly addressed with well-established tech- exception. To facilitate adoption tcpcrypt provides back- niques. For instance, where users actually have con- wards compatibility with legacy TCP stacks and middle- trol, they demonstrate that they do care about encryp- boxes. Because it is implemented in the transport layer, tion. Four years ago only around half of WiFi basesta- it protects legacy applications. However, it also provides tions used any form of encryption [3]. Today it is rare to a hook for integration with application-layer authentica- find an open basestation, other than ones which charge tion, largely obviating the need for applications to en- for Internet access. crypt their own network traffic and minimizing the need It is clear, though, that application writers have lit- for duplication of functionality. Finally, tcpcrypt mini- tle motivation: encryption rarely makes a difference to mizes the cost of key negotiation on servers; a server us- whether an application succeeds.
    [Show full text]
  • Building an Application-Aware Ipsec Policy System
    Building an Application-aware IPsec Policy System Heng Yin Haining Wang Department of Computer Science The College of William and Mary Williamsburg, VA 23187 {hyin,hnw}@cs.wm.edu Abstract ability of the network-layer, such as IP spoofing [25] and IP fragmentation attacks [16], to sabotage end-to- As a security mechanism at the network-layer, the IP se- end communications. The IP security (IPsec) proto- curity protocol (IPsec) has been available for years, but col [17, 18, 19, 27] is a suite of protocols that secure data its usage is limited to Virtual Private Networks (VPNs). communications on the Internet at the network-layer. The end-to-end security services provided by IPsec have IPsec provides packet-level source authentication, data not been widely used. To bring the IPsec services into confidentiality and integrity, and supports perfect for- wide usage, a standard IPsec API is a potential solution. ward security. There are two major protocols in the IPsec However, the realization of a user-friendly IPsec API in- protocol suite: the Authentication Header (AH) protocol volves many modifications on the current IPsec and In- and the Encapsulation Security Payload (ESP) protocol. ternet Key Exchange (IKE) implementations. An alter- The AH protocol provides source authentication and data native approach is to configure application-specific IPsec integrity, while the ESP protocol provides data confiden- policies, but the current IPsec policy system lacks the tiality and authentication. Internet Key Exchange (IKE) knowledge of the context of applications running at up- [13, 21] is the default key agreement protocol for the es- per layers, making it infeasible to configure application- tablishment of IPsec security associations (SAs), doing specific policies in practice.
    [Show full text]