Conference Reports From

Total Page:16

File Type:pdf, Size:1020Kb

Load more

THE USENIX MAGAZINE December 2003 • volume 28 • number 6 { inside: SECURITY Perrine: The End of crypt() Passwords . Please? Wysopal: Learning Security QA from the Vulnerability Researchers Damron: Identifiable Fingerprints in Network Applications Balas: Sebek: Covert Glass-Box Host Analysis Jacobsson & Menczer: Untraceable Email Cluster Bombs Mudge: Insider Threat Singer: Life Without Firewalls Focus Issue: Security Deraison & Gula: Nessus Guest Editor: Rik Farrow Forte: Coordinated Incident Response Procedures Russell: How Are We Going to Patch All These Boxes? Kenneally: Evidence Enhancing Technology BOOK REVIEWS AND HISTORY USENIX NEWS # CONFERENCE REPORTS 12th USENIX Security Symposium The Advanced Computing Systems Association conference reports 12th USENIX Security tification. In addition, the link between Symposium identity and reputation is not addressed OUR THANKS TO THE SUMMARIZERS: in conventional systems. August 4–8, 2003 Scott A. Crosby This led to the next phase of the talk: Catherine Dodge Washington, D.C. Clif Flynt reputation. Black Unicorn’s most appro- Seung Won Jun KEYNOTE ADDRESS: REFLECTIONS priate definition is a specific characteris- David Molnar ON A DECADE OF PSEUDONYMITY tic or trait ascribed to a person or thing: Chris Ries Black Unicorn a reputation for courtesy. The value of Gelareh Taban reputation is as a predictor of behavior, Tara Whalen Summarized by Tara Whalen Black Unicorn, aka A.S.L. von Bern- as a means of valuation, and as a means hardi, kicked off the conference with his for third-party assessment. Black Uni- talk on the relationships between iden- corn took issue with the notion of repu- NOTE tation as a behavior-predictor. Reports for BSDCon ’03 arrived too late tity, reputation, and trust. Anonymity to be included in this issue. They are has negative connotations, or “sunny Black Unicorn then discussed trust; he available at http://www.usenix.org/ climes attract shady characters.”He presented several definitions, choosing publications/library/proceedings/ chose his pseudonym when the cypher- “reliance on something in the future; bsdcon03/confrpts. punks list was being archived, and sug- hope” as the most appropriate for this gested that anybody who doesn’t want to talk. The value of trust has several com- attract undue attention should probably ponents: as a means of inexpensive due diligence; as a delegation enabler; as a means to reduce robustness of envi- ronmental security; and as an indication of risk toler- ance. Black Unicorn then dis- cussed the relationships between trust, identity, and reputation, showing how factors such as credentials, Black Unicorn and Vern Paxson third-party attestation, and pick a benign pseudonym, such as “Bill certification affect trust. Smith.” Identity information can be augmented by due diligence, consequence augmen- He then launched into a detailed discus- tation (e.g., penalties for crimes), and sion of identity: its definition, its value, third-party attestation. and some common fallacies. The defini- tion he prefers is “the distinct personal- Q: Given the reticence of Americans to ity of an individual regarded as a persist- use ID cards, how will we be able to ing entity; individuality.” identify people? The value of identity encompasses both A: This problem is likely to remain. its use as a unique identifier and in There is no good answer; identity is establishing the uniqueness of a reputa- always going to be nebulous. We have tional assertion. different roles that we play, and we tend not to like third-party assertions about The problems with identity are a lack of our identities. a standard unique identifier, reliance on third-party attestation, and the absence Q: How is the use of third-party attesta- of static physical characteristics for iden- tions different from due diligence? 70 Vol. 28, No. 6 ;login: A: We often look at collections of attes- expected to fail, and the time it takes to 802.11 DENIAL-OF-SERVICE ATTACKS: REAL tations, which is better than looking at reject each query is measured. Rejecting VULNERABILITIES AND PRACTICAL SOLUTIONS EPORTS only one attestation. The problem with a query requires that the server perform John Bellardo and Stefan Savage, Uni- R third-party attestations is that these par- several math operations. Depending on versity of California, San Diego ties have limited motivation to do the organization of the 1s and 0s in the While many members of the audience proper due diligence (to save money), query, different speed optimizations may were connected to the outside world via ONFERENCE C and their own liability is limited by be performed. A program can deduce their laptops and 802.11b wireless links, insurance, which makes them less likely the positions of 1s and 0s from the time Stefan Savage demonstrated just how to be appropriately diligent. Direct expe- required to perform the math opera- insubstantial that link can be. He rience and/or lore may be better guides. tions. opened his talk by showing a graph of current network activity and then Q: Do you want different ID documents The timing attacks have been done attacked John Bellardo’s link, halting his for different purposes? many times in the past, but previous download. When this attack was started, work was done against “simple” devices A: Definitely. You have to look at the the graph showed that traffic to Bel- like smartcards. Boneh and Brumley’s agency making the attestation—what are lardo’s laptop was reduced to nearly 0 work shows that a surprising level of they qualified to say? Probably not a lot. packets, and Bellardo concurred that he noise can be introduced into the timing When looking at ID documents, you was no longer downloading any data. data without degrading it beyond have to look at what the agency is good Savage then extended the attack to the usability. Complex systems with multi- at attesting. rest of the audience, and I can confirm ple applications running simultaneously, that my connection to the outside world Q: Considering this issue from a cultural or even the variance of network latency, was gone. This lasted a few seconds after perspective: Identity is partially defined do not produce enough noise to disguise which Savage discontinued the attack, by race, religion, etc., and this affects the time difference required to perform and service was restored. one’s reputation. Comment? the analysis. He then described the two denial-of-ser- A: I agree. A lot of reputation is tied up OpenSSL was chosen for this work vice attacks he used, both of which use in name, for example, and differs from because the package is used in many legitimate features of the 802.11b proto- culture to culture (e.g., Europe vs. US). other applications, including mod_SSL, col. The first attack, which disabled only Look at what’s used for credibility: in stunnel, sNFS, and more. Of the applica- a single 802.11b user, used a deauthenti- Europe, it’s family history, unlike in the tions examined, only the Mozilla NSS cation attack. In a normal conversation US. packages defaulted to secure behavior. between an 802.11b client and access Because the RSA algorithm requires point, the client requests and receives an REFEREED PAPERS: ATTACKS many multiplications of very large num- authentication. At any point in the con- Summarized by Clif Flynt bers, most implementations use arith- versation, the client can request that the REMOTE TIMING ATTACKS ARE PRACTICAL metic optimization techniques to speed session be deauthenticated. The deau- David Brumley and Dan Boneh, up encrypting and decrypting. These thentication request is not a secure mes- Stanford University techniques are sensitive to certain bit sage; thus one client can send a message The authors received the Best Paper patterns in the test and real key, making to deauthenticate another client. Once a award for their report on the viability of a message rejection faster or slower session has been deauthenticated, the timing attacks on the RSA algorithm as depending on how closely the bit pat- original client must return to the begin- implemented in OpenSSL. They proved terns of the test key match the real key. A ning of the conversation with the AP that they could extract RSA private keys, defense against this attack is to use RSA before transmitting any more informa- not only when running on the same blinding, in which the client and server tion. should decrypt a random string as well hardware as the secure application, but He described a simple technique to pro- as the actual encrypted text to provide a also across a network including several tect against this attack. When the AP random decryption time. This produces routers. receives a deauthenticate request, it a 2–10% hit in performance. Brumley should hold the request for a period of Dan Boneh described how a timing found that this was sufficient to prevent time before implementing it. If a fresh attack works and how to defend against a successful timing analysis. This is data packet from the deauthenticating it. In a timing attack, the secure server is implemented by default in versions of sent many different queries that are OpenSSL after version 0.9.7b. December 2003 ;login: 12TH USENIX SECURITY SYMPOSIUM 71 client is received, the AP will not process into the packets and modify it. The tory entry cache, and others. Since the the deauthenticate request. defense against this attack is simply to paper was written, the Bro IDS and the reject unreasonably large values in the Linux vulnerabilities have been Savage described other potential attacks NAV field. In actual use, legitimate val- addressed. based on fields designed to enable power ues are always under 3 ms. conservation and reduce packet colli- Crosby described several alternative sions. However, when they implemented DENIAL OF SERVICE VIA ALGORITHMIC hash implementations and discussed some of these attacks they discovered COMPLEXITY ATTACKS their strengths and weaknesses.
Recommended publications
  • Email Transport Encryption STARTTLS Vs. DANE Vs. MTA-STS

    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.
  • MTA STS Improving Email Security.Pdf

    MTA STS Improving Email Security.Pdf

    Improving Email Security with the MTA-STS Standard By Brian Godiksen An Email Best Practices Whitepaper CONTENTS Executive Overview 03 Why Does Email Need Encryption in Transit? 04 The Problem with “Opportunistic Encryption” 07 The Anatomy of a Man-in-the-Middle Attack 08 The Next Major Step with Email Encryption: MTA-STS 10 What Steps Should Senders Take to Adopt MTA-STS? 11 About SocketLabs 12 Brian Godiksen Brian has been helping organizations optimize email deliverability since joining SocketLabs in 2011. He currently manages a team of deliverability analysts that consult with customers on best infrastructure practices, including email authentication implementation, bounce processing, IP address warm-up, and email marketing list management. Brian leads the fight against spam and email abuse at SocketLabs by managing compliance across the platform. He is an active participant in key industry groups such as M3AAWG and the Email Experience Council. You can read more of Brian’s content here on the SocketLabs website. ©2019 SocketLabs 2 Executive The Edward Snowden leaks of 2013 opened many peoples’ eyes to the fact that mass surveillance was possible by Overview intercepting and spying on email transmissions. Today, compromised systems, database thefts, and technology breaches remain common fixtures in news feeds around the world. As a natural response, the technology industry is rabidly focused on improving the security and encryption of communications across all platforms. Since those early days of enlightenment, industry experts have discussed and attempted a variety of new strategies to combat “pervasive monitoring” of email channels. While pervasive monitoring assaults can take many forms, the most prominent forms of interference were man-in-the-middle (MitM) attacks.
  • Secure Shell- Its Significance in Networking (Ssh)

    Secure Shell- Its Significance in Networking (Ssh)

    International Journal of Application or Innovation in Engineering & Management (IJAIEM) Web Site: www.ijaiem.org Email: [email protected] Volume 4, Issue 3, March 2015 ISSN 2319 - 4847 SECURE SHELL- ITS SIGNIFICANCE IN NETWORKING (SSH) ANOOSHA GARIMELLA , D.RAKESH KUMAR 1. B. TECH, COMPUTER SCIENCE AND ENGINEERING Student, 3rd year-2nd Semester GITAM UNIVERSITY Visakhapatnam, Andhra Pradesh India 2.Assistant Professor Computer Science and Engineering GITAM UNIVERSITY Visakhapatnam, Andhra Pradesh India ABSTRACT This paper is focused on the evolution of SSH, the need for SSH, working of SSH, its major components and features of SSH. As the number of users over the Internet is increasing, there is a greater threat of your data being vulnerable. Secure Shell (SSH) Protocol provides a secure method for remote login and other secure network services over an insecure network. The SSH protocol has been designed to support many features along with proper security. This architecture with the help of its inbuilt layers which are independent of each other provides user authentication, integrity, and confidentiality, connection- oriented end to end delivery, multiplexes encrypted tunnel into several logical channels, provides datagram delivery across multiple networks and may optionally provide compression. Here, we have also described in detail what every layer of the architecture does along with the connection establishment. Some of the threats which Ssh can encounter, applications, advantages and disadvantages have also been mentioned in this document. Keywords: SSH, Cryptography, Port Forwarding, Secure SSH Tunnel, Key Exchange, IP spoofing, Connection- Hijacking. 1. INTRODUCTION SSH Secure Shell was first created in 1995 by Tatu Ylonen with the release of version 1.0 of SSH Secure Shell and the Internet Draft “The SSH Secure Shell Remote Login Protocol”.
  • HTTP2 Explained

    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.
  • You Really Shouldn't Roll Your Own Crypto: an Empirical Study of Vulnerabilities in Cryptographic Libraries

    You Really Shouldn't Roll Your Own Crypto: an Empirical Study of Vulnerabilities in Cryptographic Libraries

    You Really Shouldn’t Roll Your Own Crypto: An Empirical Study of Vulnerabilities in Cryptographic Libraries Jenny Blessing Michael A. Specter Daniel J. Weitzner MIT MIT MIT Abstract A common aphorism in applied cryptography is that cryp- The security of the Internet rests on a small number of open- tographic code is inherently difficult to secure due to its com- source cryptographic libraries: a vulnerability in any one of plexity; that one should not “roll your own crypto.” In par- them threatens to compromise a significant percentage of web ticular, the maxim that complexity is the enemy of security traffic. Despite this potential for security impact, the character- is a common refrain within the security community. Since istics and causes of vulnerabilities in cryptographic software the phrase was first popularized in 1999 [52], it has been in- are not well understood. In this work, we conduct the first voked in general discussions about software security [32] and comprehensive analysis of cryptographic libraries and the vul- cited repeatedly as part of the encryption debate [26]. Conven- nerabilities affecting them. We collect data from the National tional wisdom holds that the greater the number of features Vulnerability Database, individual project repositories and in a system, the greater the risk that these features and their mailing lists, and other relevant sources for eight widely used interactions with other components contain vulnerabilities. cryptographic libraries. Unfortunately, the security community lacks empirical ev- Among our most interesting findings is that only 27.2% of idence supporting the “complexity is the enemy of security” vulnerabilities in cryptographic libraries are cryptographic argument with respect to cryptographic software.
  • SSL Checklist for Pentesters

    SSL Checklist for Pentesters

    SSL Checklist for Pentesters Jerome Smith BSides MCR, 27th June 2014 # whoami whoami jerome • Pentester • Author/trainer – Hands-on technical – Web application, infrastructure, wireless security • Security projects – Log correlation – Dirty data – Incident response exercises • Sysadmin • MSc Computing Science (Dist) • www.exploresecurity.com | @exploresecurity Introduction • Broad review of SSL/TLS checks – Viewpoint of pentester – Pitfalls – Manually replicating what tools do (unless you told the client that SSL Labs would be testing them ) – Issues to consider reporting (but views are my own) • While SSL issues are generally low in priority, it’s nice to get them right! • I’m not a cryptographer: this is all best efforts SSLv2 • Flawed, e.g. no handshake protection → MITM downgrade • Modern browsers do not support SSLv2 anyway – Except for IE but it’s disabled by default from IE7 – That mitigates the risk these days – http://en.wikipedia.org/wiki/Transport_Layer_Security#W eb_browsers • OpenSSL 1.0.0+ doesn’t support it – Which means SSLscan won’t find it – General point: tools that dynamically link to an underlying SSL library in the OS can be limited by what that library supports SSLv2 • Same scan on different OpenSSL versions: SSLv2 • testssl.sh warns you – It can work with any installed OpenSSL version • OpenSSL <1.0.0 s_client -ssl2 switch – More on this later • Recompile OpenSSL – http://blog.opensecurityresearch.com/2013/05/fixing-sslv2-support- in-kali-linux.html • SSLyze 0.7+ is statically linked – Watch out for bug https://github.com/iSECPartners/sslyze/issues/73
  • Security Economics in the HTTPS Value Chain

    Security Economics in the HTTPS Value Chain

    Security Economics in the HTTPS Value Chain Hadi Asghari*, Michel J.G. van Eeten*, Axel M. Arnbak+ & Nico A.N.M. van Eijk+1 * [email protected], [email protected] Delft University of Technology, Faculty of Technology Policy and Management + [email protected], [email protected] University van Amsterdam, Faculty of Law, Institute for Information Law Abstract. Even though we increasingly rely on HTTPS to secure Internet communications, several landmark incidents in recent years have illustrated that its security is deeply flawed. We present an extensive multi-disciplinary analysis that examines how the systemic vulnerabilities of the HTTPS authentication model could be addressed. We conceptualize the security issues from the perspective of the HTTPS value chain. We then discuss the breaches at several Certificate Authorities (CAs). Next, we explore the security incentives of CAs via the empirical analysis of the market for SSL certificates, based on the SSL Observatory dataset. This uncovers a surprising pattern: there is no race to the bottom. Rather, we find a highly concentrated market with very large price differences among suppliers and limited price competition. We explain this pattern and explore what it tells us about the security incentives of CAs, including how market leaders seem to benefit from the status quo. In light of these findings, we look at regulatory and technical proposals to address the systemic vulnerabilities in the HTTPS value chain, in particular the EU eSignatures proposal that seeks to strictly regulate HTTPS communications. Keywords: HTTPS, Cybersecurity, Internet Governance, Constitutional Values, E-Commerce, Value Chain Analysis, Security Economics, eSignatures Regulation, SSL, TLS, Digital Certificates, Certificate Authorities.
  • An Analysis of the Transport Layer Security Protocol

    An Analysis of the Transport Layer Security Protocol

    An Analysis of the Transport Layer Security Protocol Thyla van der Merwe Thesis submitted to the University of London for the degree of Doctor of Philosophy Information Security Group School of Mathematics and Information Security Royal Holloway, University of London 2018 Declaration These doctoral studies were conducted under the supervision of Professor Kenneth G. Paterson. The work presented in this thesis is the result of original research I conducted, in collabo- ration with others, whilst enrolled in the School of Mathematics and Information Security as a candidate for the degree of Doctor of Philosophy. This work has not been submitted for any other degree or award in any other university or educational establishment. Thyla van der Merwe March, 2018 2 Dedication To my niece, Emma. May you always believe in your abilities, no matter what anybody tells you, and may you draw on the strength of our family for support, as I have done (especially your Gogo, she’s one tough lady). “If you’re going through hell, keep going.” Winston Churchill 3 Abstract The Transport Layer Security (TLS) protocol is the de facto means for securing commu- nications on the World Wide Web. Originally developed by Netscape Communications, the protocol came under the auspices of the Internet Engineering Task Force (IETF) in the mid 1990s and today serves millions, if not billions, of users on a daily basis. The ubiquitous nature of the protocol has, especially in recent years, made the protocol an attractive target for security researchers. Since the release of TLS 1.2 in 2008, the protocol has suffered many high-profile, and increasingly practical, attacks.
  • Communication & Network Security

    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

    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.
  • Applied Crypto Hardening

    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 .........................................
  • The Heartbleed Bug: an Open Secure Sockets Layer Vulnerability

    The Heartbleed Bug: an Open Secure Sockets Layer Vulnerability

    International Journal of Science and Research (IJSR) ISSN (Online): 2319-7064 Impact Factor (2012): 3.358 The Heartbleed Bug: An Open Secure Sockets Layer Vulnerability Thabiso Peter Mpofu1, Noe Elisa2, Nicholaus Gati3 1M. Tech. Student, Department of Computer Science, School of IT, Jawaharlal Nehru Technological University Hyderabad, India 2, 3M. Tech. Student, Department of Computer Networks and Information Security, School of IT, Jawaharlal Nehru Technological University Hyderabad, India 3M. Tech Student, Department of Computer Networks and Information Security, School of IT, Jawaharlal Nehru Technological University Hyderabad, India, Abstract: The Open Secure Sockets Layer (OpenSSL) is used to provide a secure platform for transactions that happen over the internet. About two thirds of the servers on the internet use the OpenSSL platform to provide secure transaction over the internet. The OpenSSL is a widely used open source implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS). Transactions such as online shopping, emails and online banking are carried out on the internet through the OpenSSL and other platforms which provide a security. Vulnerabilities have however been found in the OpenSSL that has resulted in a wide public outcry all over the world. A vulnerability referred to as the Heartbleed Bug has sent shockwaves all over the internet. From the study we conducted, the scope of the data that has been potentially compromised is astronomical and includes usernames, passwords, bank account and credit card numbers, medical data, documents in online cloud storage. Not only has all of this user data been directly compromised, but, what are worse, the private keys of the servers running the vulnerable versions of OpenSSL were also almost certainly compromised.