MTA STS Improving Email Security.Pdf
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Email Transport Encryption STARTTLS Vs. DANE Vs. MTA-STS
Email Transport Encryption STARTTLS vs. DANE vs. MTA-STS Delimitation This document deals with the encrypted transport of messages between two email servers. Encryption during transport is crucial for a basic level of security for the exchange of messages. The exchange of messages between an email client and a server or the end-to-end encryption of messages are not covered in this article. If the aim is to create a secure overall system, these aspects should be considered in addition to the recommendations in this article. Initial situation When the first standard for the Simple Mail Transfer Protocol (in short: SMTP) was adopted, encryption of the transport was not included. All messages were exchanged as plain text between the servers. They were thus basically readable for anyone who could tap into the data exchange between the two servers. This only changed with the introduction of the SMTP Service Extensions for Extend SMTP (ESMTP for short), which made it possible to choose encrypted transport as an opportunistic feature of data exchange. Opportunistic, because it had to be assumed that not all servers would be able to handle transport encryption. They should only encrypt when it is opportune; encryption is not mandatory. To indicate the basic ability to encrypt to a sending server, it was agreed that the receiving server should send the keyword STARTTLS at the beginning of an ESMTP transport session. STARTTLS STARTTLS can encrypt the transport between two email servers. The receiving server signals the sending server that it is capable of encrypting after a connection is established and in the ESMTP session. -
Zix Wins 5-Vendor Email Encryption Shootout Email Encryption Has Come a Long Way Since Our Last Review
Reprint THE CONNECTED ENTERPRISE MARCH 13, 2017 Zix wins 5-vendor email encryption shootout Email encryption has come a long way since our last review BY DAVID STROM, NETWORK WORLD terms of the flexibility of various encryption While these personal encryption products protocols used, along with DLP features that are improvements, there are also steps mail encryption products have are built-in along with a simple and single forward for the enterprise encryption email made major strides since we last pricing structure -- all things that Zix excels. user. Some products, such as Zix, hide the looked at them nearly two years All of these encryption products will cost encryption key process entirely from the ago. They have gotten easier you a few dollars a month per user. While user, so well that you might not even know to use and deploy, thanks to a that doesn’t sound like much, if you have that an encrypted message has passed from Ecombination of user interface and encryption an installation of several thousand users, sender to recipient. key management improvements, and are at the price tag could add up. However, the Others, such as Virtru and HPE/Voltage, the point where encryption can almost be alternative is having your email stream use identity-based encryption management called effortless on the part of the end user. available to anyone with a simple collection to verify a new recipient in their systems. Our biggest criticism in 2015 was that the of tools that even teens can master. Once a user new to these products products couldn’t cover multiple use cases, clicks on a confirmation email, they are such as when a user switches from reading Trends and bright spots forever allowed access, their emails are emails on their smartphone to moving to a In 2015, we said that gateways may have automatically decrypted, and there is no webmailer to composing messages on their fallen out of favor, but that trend has been need for any further effort to keep track of or Outlook desktop client. -
HTTP2 Explained
HTTP2 Explained Daniel Stenberg Mozilla Corporation [email protected] ABSTRACT credits to everyone who helps out! I hope to make this document A detailed description explaining the background and problems better over time. with current HTTP that has lead to the development of the next This document is available at http://daniel.haxx.se/http2. generation HTTP protocol: HTTP 2. It also describes and elaborates around the new protocol design and functionality, 1.3 License including some implementation specifics and a few words about This document is licensed under the the future. Creative Commons Attribution 4.0 This article is an editorial note submitted to CCR. It has NOT license: been peer reviewed. The author takes full responsibility for this http://creativecommons.org/licenses/by/4.0/ article’s technical content. Comments can be posted through CCR Online. 2. HTTP Today Keywords HTTP 1.1 has turned into a protocol used for virtually everything HTTP 2.0, security, protocol on the Internet. Huge investments have been done on protocols and infrastructure that takes advantage of this. This is taken to the 1. Background extent that it is often easier today to make things run on top of HTTP rather than building something new on its own. This is a document describing http2 from a technical and protocol level. It started out as a presentation I did in Stockholm in April 2014. I've since gotten a lot of questions about the contents of 2.1 HTTP 1.1 is Huge that presentation from people who couldn't attend, so I decided to When HTTP was created and thrown out into the world it was convert it into a full-blown document with all details and proper probably perceived as a rather simple and straight-forward explanations. -
Communication & Network Security
6/13/19 Communication & Network Security MIS-5903 http://community.mis.temple.edu/mis5903sec011s17/ OSI vs. TCP/IP Model • Transport also called Host-to-Host in TCP/IP model. Encapsulation • System 1 is a “subject” (client) • System 2 has the “object” (server) 1 6/13/19 OSI Reference Notice: • Segments • Packets (Datagrams) • Frames • Bits Well known ports Protocol TCP/UDP Port Number File Transfer Protocol (FTP) (RFC 959) TCP 20/21 Secure Shell (SSH) (RFC 4250-4256) TCP 22 Telnet (RFC TCP 23 854) Simple Mail Transfer Protocol (SMTP) (RFC 5321) TCP 25 Domain Name System (DNS) (RFC 1034-1035) TCP/UDP 53 Dynamic Host Configuration Protocol (DHCP) (RFC 2131) UDP 67/68 Trivial File Transfer Protocol (TFTP) (RFC 1350) UDP 69 Hypertext Transfer Protocol (HTTP) (RFC 2616) TCP 80 Post Office Protocol (POP) version 3 (RFC 1939) TCP 110 Network Time Protocol (NTP) (RFC 5905) UDP 123 NetBIOS (RFC TCP/UDP 1001-1002) 137/138/139 Internet Message Access Protocol (IMAP) (RFC 3501) TCP 143 Well known ports (continued) Protocol TCP/UDP Port Number Simple Network Management Protocol (SNMP) UDP (RFC 1901-1908, 3411-3418) 161/162 Border Gateway Protocol (BGP) (RFC 4271) TCP 179 Lightweight Directory Access Protocol (LDAP) (RFC 4510) TCP/UDP 389 Hypertext Transfer Protocol over SSL/TLS (HTTPS) (RFC 2818) TCP 443 Line Print Daemon (LPD) TCP 515 Lightweight Directory Access Protocol over TLS/SSL (LDAPS) (RFC 4513) TCP/UDP 636 FTP over TLS/SSL (RFC 4217) TCP 989/990 Microsoft SQL Server TCP 1433 Oracle Server TCP 1521 Microsoft Remote Desktop Protocol (RDP) TCP 3389 • http://www.iana.org/assignments/service-names-port- numbers/service-names-port-numbers.xml. -
Empfehlungen Für Den Einsatz Von Transportverschlüsselung Zwischen Mailservern
Empfehlungen für den Einsatz von Transportverschlüsselung zwischen Mailservern 11.08.2017 Empfehlungen für Transportverschlüsselung zwischen Mailservern Seite 2 von 19 Dokument-Informationen Autoren Antje Bendrich, Jürgen Brauckmann, Lars Weber, Marc Thomas, Stefan Kelm Dateiname smtp-transportverschluesslung.pdf letzte Bearbeitung 15. August 2017 Seitenzahl 19 Version Datum Autor(en) Änderungen 0.1 1.1.1970 Marc Thomas Formatvorlage 0.2 28.11.2016 Marc Thomas Struktur, Inhalt 0.3 07.12.2016 Lars Weber Kapitel 2.4, 3 0.4 24.02.2017 Marc Thomas Kapitel 4 0.5 27.03.2017 Stefan Kelm QA 0.6 28.03.2017 Antje Bendrich QA 0.7 01.06.2017 Jürgen Brauckmann QA 0.8 13.06.2017 Lars Weber Kapitel 2.4.3 0.9 11.08.2017 Lars Weber Kapitel 2.4 überarbeitet ©2017 by DFN-CERT Services GmbH / All Rights reserved. Stand: 11.08.2017 Empfehlungen für Transportverschlüsselung zwischen Mailservern Seite 3 von 19 Inhaltsverzeichnis 1. Einleitung 4 2. TLS-Konfiguration 4 2.1. SSL/TLS-Protokolle . .5 2.2. SSL/TLS-Algorithmen . .6 2.3. SSL/TLS-Parameter . .7 2.4. MTA-Konfiguration . .8 2.4.1. Grenzen der Konfiguration . .8 2.4.2. Postfix . .9 2.4.3. Exim . 11 3. DNS-based Authentication of Named Entities (DANE) 14 3.1. Postfix . 15 3.2. Exim . 15 4. Best-Practices-Konfiguration 16 4.1. Postfix . 16 4.2. Exim . 17 A. Quellen 19 ©2017 by DFN-CERT Services GmbH / All Rights reserved. Stand: 11.08.2017 Empfehlungen für Transportverschlüsselung zwischen Mailservern Seite 4 von 19 1. Einleitung Moderne Bürokommunikation läuft zum großen Teil über E-Mail. -
Efail: Breaking S/MIME and Openpgp Email Encryption Using Exfiltration Channels
Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels Damian Poddebniak and Christian Dresen, Münster University of Applied Sciences; Jens Müller, Ruhr University Bochum; Fabian Ising and Sebastian Schinzel, Münster University of Applied Sciences; Simon Friedberger, NXP Semiconductors, Belgium; Juraj Somorovsky and Jörg Schwenk, Ruhr University Bochum https://www.usenix.org/conference/usenixsecurity18/presentation/poddebniak This paper is included in the Proceedings of the 27th USENIX Security Symposium. August 15–17, 2018 • Baltimore, MD, USA ISBN 978-1-939133-04-5 Open access to the Proceedings of the 27th USENIX Security Symposium is sponsored by USENIX. Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels Damian Poddebniak1, Christian Dresen1, Jens Muller¨ 2, Fabian Ising1, Sebastian Schinzel1, Simon Friedberger3, Juraj Somorovsky2, and Jorg¨ Schwenk2 1Munster¨ University of Applied Sciences 2Ruhr University Bochum 3NXP Semiconductors, Belgium Abstract is designed to protect user data in such scenarios. With end-to-end encryption, the email infrastructure becomes OpenPGP and S/MIME are the two prime standards merely a transportation service for opaque email data and for providing end-to-end security for emails. We de- no compromise – aside from the endpoints of sender or scribe novel attacks built upon a technique we call mal- receiver – should affect the security of an end-to-end en- leability gadgets to reveal the plaintext of encrypted crypted email. emails. We use CBC/CFB gadgets to inject malicious plaintext snippets into encrypted emails. These snippets S/MIME and OpenPGP. The two most prominent stan- abuse existing and standard conforming backchannels to dards offering end-to-end encryption for email, S/MIME exfiltrate the full plaintext after decryption. -
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 ......................................... -
Network Vulnerability Scan with Openvas Report
Network Vulnerability Scan with OpenVAS Report 10.8.0.1 (Metasploitable2) Summary Overall risk level: High Risk ratings: High: 13 Medium: 20 Low: 69 Info: 1 Scan information: Start time: 2018-03-02 11:24:54 Finish time: 2018-03-02 12:02:48 Scan duration: 37 min, 54 sec Tests performed: 103/103 Scan status: Finished Findings Check for rexecd Service (port 512/tcp) The rexecd Service is not allowing connections from this host. Details Risk description: Rexecd Service is running at this Host. Rexecd (Remote Process Execution) has the same kind of functionality that rsh has : you can execute shell commands on a remote computer. The main difference is that rexecd authenticate by reading the username and password *unencrypted* from the socket. Recommendation: Disable rexec Service. Read more about this issue: https//web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-1999-0618 Check for rlogin Service (port 513/tcp) The service is misconfigured so it is allowing conntections without a password. Details Risk description: rlogin has several serious security problems, - All information, including passwords, is transmitted unencrypted. - .rlogin (or .rhosts) file is easy to misuse (potentially allowing anyone to login without a password) Impact Level: System This remote host is running a rlogin service. Recommendation: Disable rlogin service and use ssh instead. Read more about this issue: https//web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-1999-0651 https//web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-1999-0651 http//en.wikipedia.org/wiki/Rlogin http//www.ietf.org/rfc/rfc1282.txt DistCC Detection (port 3632/tcp) No evidence Details Risk description: DistCC is a program to distribute builds of C, C++, Objective C or Objective C++ code across several machines on a network. -
CPA-SC DESKTOP EMAIL ENCRYPTION 1.1 DOC Version 1.1
NCSC-1844117881-471 CPA SECURITY CHARACTERISTIC CPA-SC DESKTOP EMAIL ENCRYPTION 1.1 DOC Version 1.1 Crown Copyright 2018 – All Rights Reserved CPA Security Characteristics for CPA-SC Desktop Email Encryption 1.1 doc 17th October 2018 Document History Version Date Description 0.0 6th March 2012 Preparation for industry review 1.0 17th April 2012 Updates following industry review 1.1 25th October 2018 Amended to reflect formation of NCSC This Security Characteristic is derived from the following files File Name Version Desktop Email Encryption – v1.0.cxl 1.0 Common Email Encryption – v1.4.cxl 1.4 Common Libraries – v1.6.cxl 1.6 Crypt Libraries – v1.4.cxl 1.4 Hardware Libraries – v1.3.cxl 1.3 Soft copy location: NCSC-1844117881- 471 This document is authorised by: Deputy Technical Director (Assurance), NCSC This document is issued by NCSC For queries about this document please contact: CPA Administration Team NCSC, A2i, Hubble Road Cheltenham Gloucestershire GL51 0EX United Kingdom Tel: +44 (0)1242 221 491 Email: [email protected] The CPA Authority may review, amend, update, replace or issue new Scheme Documents as may be required from time to time. Page ii CPA Security Characteristics for CPA-SC Desktop Email Encryption 1.1 doc 17th October 2018 CONTENTS REFERENCES .............................................................................................................. iv I. OVERVIEW ........................................................................................................... 1 A. Product Aims ............................................................................................... -
Lightweight Encryption for Email
Lightweight Encryption for Email Ben Adida Susan Hohenberger Ronald L. Rivest MIT MIT MIT [email protected] [email protected] [email protected] Abstract 1.1 Prior Key Management Strategies Email encryption techniques have been available for Public-key encryption has been around for 25 years. In more than a decade, yet none has been widely de- its basic form, it is well understood: a public key allows ployed. The problems of key generation, certification, for encryption, while an associated private (a.k.a. secret) and distribution have not been pragmatically addressed. key performs decryption. The complication lies in as- We recently proposed a method for implementing a sociating a public key with a user. How does Bob obtain Lightweight Public Key Infrastructure (PKI) for email Alice’s public key? How can Bob be certain that the pub- authentication using recent developments in identity- lic key he has obtained is indeed Alice’s, and not some based cryptography and today’s existing Internet infras- eavesdropper’s? tructure. In classic public-key cryptosystems like RSA [11], El While this solution works well for email authentica- Gamal [7], or Cramer-Shoup [5], each user generates a tion, email encryption exhibits a different threat model keypair. The association between a public key and an that requires special treatment. In this work, we discuss identity is then certified by the digital signature of some how to achieve email encryption and present a realistic authority. With S/MIME [10], these certification author- deployment and adoption process, while respecting the ities form an organizational hierarchy. With PGP [14], current functionality and expectations of email. -
Email Encryption Isn't Enough
Email Encryption Isn’t Enough Five Best Practices to Safeguard Against 3rd Party Cyber Risk Executive Summary CISOs and other IT executives cringe when they think about an email’s journey across the internet, undergoing eavesdropping by criminals, companies and governments along the way. Or that it may sit in the 3rd party recipient’s email server for months, completely outside your control. Peers tell you about their non-compliance fines from breaches of personal information, while you worry about theft of intellectual property giving a competitor the edge. Many firms try to address these problems by encrypting their most sensitive communications but discover a myriad of shortcomings. You can’t give users a tool that prompts questions like, “What is my recipient’s public key and why do I need it?” You need secure email that still works like normal email, especially for 3rd party recipients who may be customers, clients, and partners in other organizations. The kicker: you can’t guarantee email privacy if your cloud provider has the encryption keys, or if you don’t properly govern and monitor your insiders. Embrace the following five best practices to go beyond encryption and fully safeguard your organization’s email privacy. SHARE TWEET SHARE 2 | www.accellion.com SECURE EMAIL BEST PRACTICE Ensure Employees Adopt Secure Email 1 Incorporate Simple Security and Governance into Users’ Workflows Security professionals abhor the risks of standard email traveling over the internet in the clear. You want standard, compliant encryption—AES-256 at rest and SSL/TLS in transit—to thwart scans by advertisers, malware and foreign powers. -
Easy Email Encryption with Easy Key Management
Why Joanie Can Encrypt: Easy Email Encryption with Easy Key Management John S. Koh Steven M. Bellovin Jason Nieh Columbia University Columbia University Columbia University New York, NY New York, NY New York, NY koh@cs:columbia:edu smb@cs:columbia:edu nieh@cs:columbia:edu Abstract subjected to a simple password recovery and reset attack Email privacy is of crucial importance. Existing email encryp- which granted the attacker full access to her personal email tion approaches are comprehensive but seldom used due to account on the Yahoo! Mail website. John Brennan’s AOL their complexity and inconvenience. We take a new approach web email account was compromised via social engineering. to simplify email encryption and improve its usability by im- Adversaries also sometimes seize entire email servers such plementing receiver-controlled encryption: newly received as in the cases of cock.li and TorMail [30, 41], or compromise messages are transparently downloaded and encrypted to a them, such as in the Sony Pictures email leaks [43]. locally-generated key; the original message is then replaced. The common thread is that a compromise exposes the To avoid the problem of moving a single private key between entire history of affected users’ emails after a single breach. devices, we implement per-device key pairs: only public keys With the explosive growth in cloud storage, it is easy to need be synchronized via a simple verification step. Com- keep gigabytes of old emails at no cost. Gmail’s massive promising an email account or server only provides access storage capacity—up to 15 GB for free, or 30 TB for paid to encrypted emails.