security June 2014

security@lists.fedoraproject.org

17 participants
19 discussions

[Secure Coding] master: Removed file not ready for publication (172ce9c)
by Eric Christensen 27 Jun '14

27 Jun '14

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit 172ce9ced9270123b8ae141ee48de9f36aad301c Author: Eric Christensen <echriste(a)redhat.com> Date: Fri Jun 27 11:10:27 2014 -0400 Removed file not ready for publication >--------------------------------------------------------------- Diff suppressed because of size. To see it, use: git diff --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol ^172ce9ced9270123b8ae141ee48de9f36aad301c~1 172ce9ced9270123b8ae141ee48de9f36aad301c

1 0

[Secure Coding] master: Marked up more fo this chapter (a650892)
by Eric Christensen 27 Jun '14

27 Jun '14

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit a650892eb864fce2d6168071e01ac3cba9e5a056 Author: Eric Christensen <echriste(a)redhat.com> Date: Fri Jun 27 11:09:50 2014 -0400 Marked up more fo this chapter >--------------------------------------------------------------- ...b_Applications.xml => Web_Applications.xml.txt} | 441 ++++++++++---------- 1 files changed, 222 insertions(+), 219 deletions(-) diff --git a/defensive-coding/en-US/Web_Applications.xml b/defensive-coding/en-US/Web_Applications.xml.txt similarity index 87% copy from defensive-coding/en-US/Web_Applications.xml copy to defensive-coding/en-US/Web_Applications.xml.txt index b08d0d7..e1f270a 100644 --- a/defensive-coding/en-US/Web_Applications.xml +++ b/defensive-coding/en-US/Web_Applications.xml.txt @@ -21,7 +21,7 @@ <para>An attacker could in theory create a link that contains Javascript that will be executed in the victims browser like so:</para> <code> -http://example.com/?name=<script>alert(1)</script> +http://example.com/?name=<script>alert(1)</script> </code> </section> <section> @@ -40,10 +40,10 @@ http://example.com/?name=<script>alert(1)</script> <code> Will be escaped -<h:outputText value="#{param.name}"> +<h:outputText value="#{param.name}"> Won't be escaped (DON'T DO THIS!) -<h:outputText value="#{param.name}" escape=false> +<h:outputText value="#{param.name}" escape=false> </code> <para>Similarly Flask templates will escape content by default unless explicitly told not to.</para> @@ -62,7 +62,7 @@ from flask import g, request, flash, abort, escape @app.route('/say_hello') def say_hello(): - return "<p>Hi %s</p>" % (escape(request.args.get('name'))) + return "<p>Hi %s</p>" % (escape(request.args.get('name'))) </code> <para>You can also do this directly in Java code using Apache commons</para> @@ -70,7 +70,7 @@ def say_hello(): import static org.apache.commons.lang.StringEscapeUtils.escapeHtml; void doGet(...){ - response.getWriter().printf("<p>Hello, %s</p>", escapeHtml(request.getParameter("name"))); + response.getWriter().printf("<p>Hello, %s</p>", escapeHtml(request.getParameter("name"))); } </code> @@ -78,7 +78,7 @@ void doGet(...){ <para>You should *NOT* try to implement your own escaping mechanisms or blacklists when a better, security tested alternative is available.</para> </important> - <para>Some caveats around how to escape content correctly and safely will be covered in more details in the <<_output_escaping_and_encoding,output escaping and encoding>> section.</para> + <para>Some caveats around how to escape content correctly and safely will be covered in more details in the <_output_escaping_and_encoding,output escaping and encoding>> section.</para> <section> <title>Monitoring and validating HTTP parameters</title> @@ -120,48 +120,48 @@ def xss_protection(rsp): <para>The trouble with XSS from a browser's perspective is that is difficult to distinguish between a script that's intended to be part of a web application and a script that has been injected by an attacker. Content Security Policy (CSP) is a standard that allows application developers to specify whitelists of trusted sources for their content.</para> <para>There are however some caveats to using this feature. In-lined content is considered harmful so all content must be loadable from an external source. This means that you cannot embed scripts and styles within HTML content.</para> <code> - -<html> - <head> - <title>Example</title> -  +<html> + <head> + <title>Example</title> +  - <style> + --> + <style> #foo { padding-top: 2em; margin-left: 1.5em; }; - </style> - </head> - <body> - <div id="foo"> - <h1>Example</h1> - <p> + </style> + </head> + <body + <div id="foo"> + <h1>Example</h1> + <p> This is an example of the kind of things that you can no longer do. - You can't invoke <a id='say_hello' href="javascript:sayHello()">javascript via links</a> + You can't invoke <a id='say_hello' href="javascript:sayHello()">javascript via links</a> anymore. - </p> - <p id="bad_style" style="color:red"> + </p> + <p id="bad_style" style="color:red"> Inline styles are also prevented. - </p> - </div> + </p> + </div> -  - <script> + --> + <script> function sayHello(){ alert("Hello world"); } - </script> - </body> -</html> + </script> + </body> +</html> </code> <para>Instead you should load content from an explicit source. For example the previous code snippet may be rewritten as follows.</para> <code> @@ -186,30 +186,30 @@ document.addEventListner('DOMContentLoaded', function(){ }); </code> <code> -<html> - <head> - <link rel="stylesheet" type="text/css" href="hello.css"> - </head> - <body> - <div id="foo"> - <h1>Example</h1> - <p> +<html> + <head> + <link rel="stylesheet" type="text/css" href="hello.css"> + </head> + <body> + <div id="foo"> + <h1>Example</h1> + <p> In this example the scripts and styles are loaded from - an external source. The onclick event handler of <a id='say_hello' href="#">this link</a> + an external source. The onclick event handler of <a id='say_hello' href="#">this link</a> is handled by the external javascript source file. This can be used with CSP. - </p> - <p id="bad_style"> + </p> + <p id="bad_style"> Similarly the style of this paragrah is managed by the external CSS source. This approach can also be used with CSP. - </p> - </div> - <script type="text/javascript" src="hello.js"></script> - </body> -</html> + </p> + </div> + <script type="text/javascript" src="hello.js"></script> + </body> +</html> </code> <para>The content security policy can be set using the following headers:</para> - +<code> [options="header"] |=== | Header | Browsers @@ -224,10 +224,10 @@ document.addEventListner('DOMContentLoaded', function(){ | Chrome 14+, Safari 6+ |=== - -When specifying the header you can create a fine grained policy using a combination -of the following directives: - +</code> +<para>When specifying the header you can create a fine grained policy using a combination +of the following directives:</para> +</code> [options="header"] |=== | Directive | Description @@ -241,7 +241,7 @@ within the web application. | Allows you to set policy around valid sources for Javascript content. | object-src -| Defines valid sources of plugins such as <object>, <embed>, and <applet>. +| Defines valid sources of plugins such as <object>, <embed>, and <applet>. | style-src | Allows you to set policy around valid sources for stylesheets. @@ -251,7 +251,7 @@ within the web application. | media-src | Allows you to set policy around valid sources of HTML5 content like -<audio> and <video>. +<audio> and <video>. | frame-src | Allows you to set policy around valid sources for loading frames. @@ -283,12 +283,12 @@ specify the URI to send the CSP report to. |=== - -Most of these directives need to be applied to a source to be enforced by the browser. +</code> +<para>Most of these directives need to be applied to a source to be enforced by the browser. The exceptions being the sandbox and report-uri directives which have their own special purposes. For ther other directives you may enforce your whitelist by selective usage -of the following sources. - +of the following sources. </para> +<code> [options="headers"] |=== | Source | Description @@ -312,14 +312,16 @@ of the following sources. | An explicit URI to load content from. |=== - +</code> +<para> Creating a policy requires knowing where your web assets are coming from and restricting external sources as much as possible. Most web applications will be able to get away with disabling media, embedded content and frames entirely. The best way to retrofit a policy is to start in a restrictive mode, run your test suite and examine any reported CSP failures. The following code snippet demonstrates how you might create a policy for browsers supporting CSP. - +</para> +<code> [source,java] ---- @@ -346,9 +348,9 @@ supporting CSP. if ((browser = chrome.matcher(userAgent)).find()){ int version = Integer.parseInt(browser.group(1)); - if (version >= 25){ + if (version >= 25){ response.addHeader("Content-Security-Policy", policy); - } else if (version < 25 && version > 14){ + } else if (version < 25 ## version > 14){ response.addHeader("X-Webkit-CSP", policy); } else { log.debug("CSP not supported by : " + userAgent); @@ -359,180 +361,181 @@ supporting CSP. ---- - -=== Summary - -Using the CSP in conjunction with the aforementioned mitigation strategies -is a really good defense in depth approach to reduce the likelihood of XSS -attacks. The great thing is that it requires very little effort by web -developers to get a substantial gain in security and therefore it is something -that should be considered as a high priority for those looking to boost the -security of their applications. - -[TIP] -==== -* Validate user input against a whitelist -* Escape user controlled input -* Monitor the use of HTTP parameters for signs of attacks. -* Use CSP to limit the trusted sources of scripts in your web application. -==== - - - -== Session Hijacking - -=== Overview - -A session hijacking attack is when an attacker manages to steal an existing +</code> + </section> + <section> + <title>Summary</title> + <para>Using the CSP in conjunction with the aforementioned mitigation strategies is a really good defense in depth approach to reduce the likelihood of XSS attacks. The great thing is that it requires very little effort by web developers to get a substantial gain in security and therefore it is something that should be considered as a high priority for those looking to boost the security of their applications.</para> +<note><title>TIP</title><para><simplelist> +<member>Validate user input against a whitelist</member> +<member>Escape user controlled input</member> +<member>Monitor the use of HTTP parameters for signs of attacks.</member> +<member>Use CSP to limit the trusted sources of scripts in your web application.</member> +</simplelist></para></note> + </section> + </section> + </section> + <section> + <title>Session Hijacking</title> + <para /> + <section> + <title>Overview</title> + <para>A session hijacking attack is when an attacker manages to steal an existing users session token and impersonate them when talking to the server. Session Hijacking is one possible use of a XSS attack, although sessions may be hijacked by other means. For instance, an attacker may construct a link that pre-emptively sets a users session identifier to a known value which the user then authenticates. Other attacks only require you to be logged into the same network as the attacker and they can simply sniff the network traffic -to access your session token. +to access your session token.</para> -As a result it is essential to ensure all authenticated network traffic is + <para>As a result it is essential to ensure all authenticated network traffic is performed over a secure channel via TLS. Session tokens must be also transmitted -in a secure manner. - -=== Defending against Session Hijacking - - -==== Use non-deterministic session identifiers - -Predictable session identifiers also be used in a session hijacking attack. An attacker +in a secure manner.</para> + </section> + <section> + <title>Defending against Session Hijacking</title> + <para /> + <section> + <title>Use non-deterministic session identifiers</title> + <para>Predictable session identifiers also be used in a session hijacking attack. An attacker only has to guess a valid session identifier to impersonate a different user. Most web frameworks already include a vetted session cookie implementation. It is not recommended that you concoct your own session identification mechanism. It is however -recommended that you verify that the session identifier is suitably random. A useful tool for doing this is called link:http://lcamtuf.coredump.cx/soft/stompy.tgz[Stompy]. -Stompy is a command line entropy verifier for session cookies and XSRF tokens. +recommended that you verify that the session identifier is suitably random. A useful tool for doing this is called <ulink url="http://lcamtuf.coredump.cx/soft/stompy.tgz">Stompy</ulink>.</para> +<para>Stompy is a command line entropy verifier for session cookies and XSRF tokens.</para> + + </section> + <section> + <title>Set the HTTP Only flag</title> + <para>A good protective measure against session hijacking via XSS is to use a session cookie that cannot be accessed by client side Javascript. This -is achieved by setting the HTTP only flag on the cookie. - -For most web containers you can specify the following option in your -web.xml file. +is achieved by setting the HTTP only flag on the cookie.</para> + <para>For most web containers you can specify the following option in your web.xml file.</para> +<code> [source,xml] ---- ... - <session-config> - <cookie-config> - <http-only>true</http-only> - </cookie-config> - </session-config> + <session-config> + <cookie-config> + <http-only>true</http-only> + </cookie-config> + </session-config> ... ---- +</code> +<para>Of course the +HttpOnly+ flag can be set programmatically when +creating the cookie too.</para> -Of course the +HttpOnly+ flag can be set programmatically when -creating the cookie too. - +<code> [source,java] ---- response.addHeader("Set-Cookie", "foo=bar; HttpOnly;"); ---- - -==== Set the Secure Flag - -Setting the HttpOnly flag will prevent the session cookie from +</code> + </section> + <section> + <title>Set the Secure Flag</title> + <para>Setting the HttpOnly flag will prevent the session cookie from being accessed via client side Javascript, but it doesn't protect the token being transmitted over an insecure channel. Setting the +Secure+ flag on the session cookie will tell the browser not to transmit the -cookie over an insecure channel. +cookie over an insecure channel.</para> -Again, this can be done via the web containers web.xml file. +<para>Again, this can be done via the web containers web.xml file.</para> +<code> [source, xml] ---- ... - <session-config> - <cookie-config> - <http-only>true</http-only> - <secure>true</secure> - </cookie-config> - </session-config> + <session-config> + <cookie-config> + <http-only>true</http-only> + <secure>true</secure> + </cookie-config> + </session-config> ... ---- - -Or programatically. +</code> +<para>Or programatically.</para> +<code> [source,java] ---- response.addHeader("Set-Cookie", "foo=bar; HttpOnly; Secure;"); ---- - -==== Strict transport security (HSTS) - -Taking this a step further, you should ensure that all authenticated +</code> + </section> + <section> + <title>Strict transport security (HSTS)</title> + <para>Taking this a step further, you should ensure that all authenticated network traffic is sent via a TLS connection. Enabling HTTP Strict Transport Security informs compliant browsers to only interact with the web service via a secure HTTPS connection. This protection mechanism is most effective in preventing TLS stripping attacks and helps prevent hijacking by -ensuring a secure connection is always used with the server. +ensuring a secure connection is always used with the server.</para> -To enable HSTS you need only add a Strict-Transport-Security header to + <para>To enable HSTS you need only add a Strict-Transport-Security header to client responses with a +max-age+ value in seconds. The +max-age+ attribute indicates to the browser how long it should honour the HTST -transport request. +transport request.</para> +<code> [source,java] ---- ... response.addHeader("Strict-Transport-Security", "max-age=86400; includeSubdomains"); ... ---- - - -=== Summary - -Using a combination of all these measures will help prevent the incidence of -session hijacking on your site. - -[TIP] -==== -- *DON'T* Use deterministic session identifiers -- *DON'T* Send a session identifier via a HTTP parameter or in the URI -- *DON'T* Allow client side Javascript to have access to the session token. -- *DON'T* Send session tokens over an insecure channel -- *DON'T* Allow authenticated content to travel via HTTP -==== - - -== Click Jacking - -=== Overview - -Click Jacking is when an attacker conceals the true nature of a site using +</code> + </section> + </section> + <section> + <title>Summary</title> + <para>Using a combination of all these measures will help prevent the incidence of +session hijacking on your site.</para> + <note><title>TIP</title><para><simplelist> +<member>*DON'T* Use deterministic session identifiers</member> +<member>*DON'T* Send a session identifier via a HTTP parameter or in the URI</member> +<member>*DON'T* Allow client side Javascript to have access to the session token.</member> +<member>*DON'T* Send session tokens over an insecure channel</member> +<member>*DON'T* Allow authenticated content to travel via HTTP</member> +</simplelist></para></note> + </section> + </section> + <section> + <title>Click Jacking</title> + <para /> + <section> + <title>Overview</title> + <para>Click Jacking is when an attacker conceals the true nature of a site using techniques as cursor spoofing or iframe overlays to trick a user into -clicking on a malicious link to perform unintended actions. - -=== Content Security Policy - -The <<_content_security_policy_csp, XSS section>> introduced +clicking on a malicious link to perform unintended actions.</para> + </section> + <section> + <title>Content Security Policy</title> + <para>The <<_content_security_policy_csp, XSS section>> introduced content security policy, and defining a tight CSP can also help mitigate this class of attack. W3C currently has a link:https://www.w3.org/TR/UISafety/[working draft] -of how CSP may be futher used to mitigate user interface redressing. - -=== X-Frame-Options - -It is common for this class of attack to use iframes to obscure the +of how CSP may be futher used to mitigate user interface redressing.</para> + </section> + <section> + <title>X-Frame-Options</title> + <para>It is common for this class of attack to use iframes to obscure the actual nature of the site. The +X-Frame-Options+ header was introduced by Microsoft in IE8. It allows web application developers to prevent frame based UI redressing. All modern browsers now support this option so it -is worth turning on. +is worth turning on.</para> There are three configuration options for this header. [options="headers"] @@ -606,10 +609,10 @@ Starting from Seam 2.2.1 you can add a CSRF token to user forms as follows. [source, html] ---- -<h:form> - <s:token/> +<h:form> + <s:token/> ... -</h:form> +</h:form> ---- @@ -619,11 +622,11 @@ include the random _csrf_token. [source, html] ---- -<form method="POST" action="/transfer"> +<form method="POST" action="/transfer"> {{ form.hidden_tag() }} -  - <button type="submit">Transfer funds</button> -</form> +  + <button type="submit">Transfer funds</button> +</form> ---- @@ -773,16 +776,16 @@ session cookie by injecting the EL expression +${cookie["JSESSIONID"].value}+. [source,html] ---- - +--> ... -<h:outputText value="${param.foo}" /> +<h:outputText value="${param.foo}" /> ... ---- @@ -1086,7 +1089,7 @@ import java.nio.file.FileSystems; import java.nio.file.Files; // Restrict read / write to current user only. -Set<PosixFilePermssions> perms = PosixFilePermissions.fromString("rw-------") +Set<PosixFilePermssions> perms = PosixFilePermissions.fromString("rw-------") String prefix = null; // use default String suffix = null; // use default @@ -1143,20 +1146,20 @@ as the SAX parser will process the document on the fly. [source, xml] ---- -<account> - <username>fred</username> - <roles> - <role>staff</role> - </roles> +<account> + <username>fred</username> + <roles> + <role>staff</role> + </roles> -  - <nickname> + </nickname><roles><role>admin</role></roles><nickname>freddie + --> + <nickname> {{ user_controlled_input }} - </nickname> -</account> + </nickname> +</account> ---- @@ -1203,22 +1206,22 @@ uses entity recursion to expand a small XML document to a huge size. [source, xml] ---- - -<?xml version="1.0"?> -<!DOCTYPE lolz [ -<!ENTITY lol "lol"> -<!ELEMENT lolz (#PCDATA)> -<!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> -<!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> -<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> -<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> -<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> -<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> -<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> -<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> -<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> -]> -<lolz>&lol9;</lolz> + +<?xml version="1.0"?> +<!DOCTYPE lolz [ +<!ENTITY lol "lol"> +<!ELEMENT lolz (#PCDATA)> +<!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> +<!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> +<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> +<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> +<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> +<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> +<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> +<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> +<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> +]> +<lolz>&lol9;</lolz> ---- To protect against entity expansion in JAXP 1.3 you will need to turn on @@ -1256,11 +1259,11 @@ local or remote content. [source,xml] ---- -<?xml version="1.0" encoding="ISO-8859-1"?> -<!DOCTYPE foo [ - <!ELEMENT foo ANY > - <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> - <foo>&xxe;</foo> +<?xml version="1.0" encoding="ISO-8859-1"?> +<!DOCTYPE foo [ + <!ELEMENT foo ANY > + <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> + <foo>&xxe;</foo> ---- @@ -1349,8 +1352,8 @@ static String safeRedirect(URI baseUrl, String target){ // Assert that normalized URI hostname, port and scheme match if (baseUrl.getHost().equals(redirect.getHost()) - && baseUrl.getPort() == redirect.getPort() - && baseUrl.getScheme().equals(redirect.getScheme())){ + ## baseUrl.getPort() == redirect.getPort() + ## baseUrl.getScheme().equals(redirect.getScheme())){ return redirect.toString(); } @@ -1548,7 +1551,7 @@ it is more of an obstacle for an attack not a prevention mechanism. === Insecure transmission of session data -This has already been touched on in the <<_session_hijacking, session hijacking>> +This has already been touched on in the <<_session_hijacking, session hijacking>> section. To reiterate the main points: * Session data should *ALWAYS* be transmitted over a secure channel. @@ -1704,7 +1707,7 @@ def password_strength_check(form, field): any((sym in string.ascii_uppercase) for c in field.data) and any((sym in string.ascii_lowercase) for c in field.data) and any((sym in string.digits) for c in field.data) and - any((sym in """!@#$%^&*()-_+={}[]\|;:'"/?.>,<`~""".split()) for c in field) + any((sym in """!@#$%^#*()-_+={}[]\|;:'"/?.>,<`~""".split()) for c in field) # Form definition for user registration. @@ -2025,7 +2028,7 @@ def create_person(): ==== XML schema validation -The <<_importance_of_schema_validation,importance of XML schema validation>> +The <<_importance_of_schema_validation,importance of XML schema validation>> has already been touched on in this guide. To summarize you should explicitly validate XML input against a xsd to ensure it is a valid document. @@ -2089,7 +2092,7 @@ as much as possible. * OWASP application verification standard. -== Supporting libraries & tools +== Supporting libraries # tools * OWASP ESAPI * OWASP AntiSammy

1 0

TLS Survey for May 2014
by Hubert Kario 24 Jun '14

24 Jun '14

Hi all, I've scanned the Alexa top 1 million again. Since we've had Heartbleed in between this and previous scan, the differences are visible. Key points: * percent of RC4 only servers is falling (is 1.38%, was 1.77%) * percent of sites that prefer RC4 has fallen by small amount (is 18.7%, was 19.5%)... * ...but percent of sites that use RC4 in TLS1.1+ has grown (is 11.78%, was 10.4%) * percent of certificates signed with SHA256 has grown significantly (is 10%, was 5.2%) * emergence of first sites that use only certificates signed with ECDSA * number of sites supporting TLS1.2 continues to grow (is 54%, was 47%) SSL/TLS survey of 318366 websites from Alexa's top 1 million Stats only from connections that did provide valid certificates (or anonymous DH from servers that do also have valid certificate installed) Supported Ciphers Count Percent -------------------------+---------+------- 3DES 276767 86.9336 3DES Only 138 0.0433 AES 296231 93.0473 AES Only 931 0.2924 AES-CBC Only 589 0.185 AES-GCM 121700 38.2264 AES-GCM Only 4 0.0013 CAMELLIA 127348 40.0005 CAMELLIA Only 1 0.0003 CHACHA20 19834 6.2299 RC4 283666 89.1006 RC4 Only 4401 1.3824 RC4 Preferred 59422 18.6647 RC4 forced in TLS1.1+ 37507 11.7811 z:ADH-DES-CBC-SHA 1031 0.3238 z:ADH-SEED-SHA 863 0.2711 z:AECDH-NULL-SHA 9 0.0028 z:DES-CBC-MD5 254 0.0798 z:DES-CBC-SHA 60478 18.9964 z:DHE-RSA-SEED-SHA 51890 16.2989 z:ECDHE-RSA-NULL-SHA 7 0.0022 z:EDH-RSA-DES-CBC-SHA 49291 15.4825 z:EXP-ADH-DES-CBC-SHA 625 0.1963 z:EXP-DES-CBC-SHA 49466 15.5375 z:EXP-EDH-RSA-DES-CBC-SHA 35342 11.1011 z:EXP-RC2-CBC-MD5 46932 14.7415 z:IDEA-CBC-MD5 27 0.0085 z:IDEA-CBC-SHA 51847 16.2853 z:NULL-MD5 319 0.1002 z:NULL-SHA 313 0.0983 z:NULL-SHA256 10 0.0031 z:RC2-CBC-MD5 281 0.0883 z:SEED-SHA 65444 20.5562 Supported Handshakes Count Percent -------------------------+---------+------- DHE 153909 48.3434 ECDHE 134412 42.2193 Supported PFS Count Percent PFS Percent -------------------------+---------+--------+----------- DH,1024bits 145147 45.5912 94.307 DH,2048bits 7568 2.3771 4.9172 DH,3072bits 2 0.0006 0.0013 DH,3248bits 2 0.0006 0.0013 DH,4096bits 428 0.1344 0.2781 DH,4097bits 2 0.0006 0.0013 DH,512bits 92 0.0289 0.0598 DH,768bits 673 0.2114 0.4373 ECDH,B-163,163bits 1 0.0003 0.0007 ECDH,B-571,570bits 294 0.0923 0.2187 ECDH,P-224,224bits 3 0.0009 0.0022 ECDH,P-256,256bits 133565 41.9533 99.3698 ECDH,P-384,384bits 165 0.0518 0.1228 ECDH,P-521,521bits 450 0.1413 0.3348 Prefer DH,1024bits 98851 31.0495 64.2269 Prefer DH,2048bits 2143 0.6731 1.3924 Prefer DH,4096bits 34 0.0107 0.0221 Prefer DH,512bits 1 0.0003 0.0006 Prefer DH,768bits 74 0.0232 0.0481 Prefer ECDH,B-163,163bits 1 0.0003 0.0007 Prefer ECDH,B-571,570bits 236 0.0741 0.1756 Prefer ECDH,P-256,256bits 94746 29.7601 70.4892 Prefer ECDH,P-384,384bits 115 0.0361 0.0856 Prefer ECDH,P-521,521bits 409 0.1285 0.3043 Prefer PFS 196610 61.756 0 Support PFS 245327 77.0582 0 Certificate sig alg Count Percent -------------------------+---------+-------- None 9994 3.1392 ecdsa-with-SHA256 2 0.0006 sha1WithRSAEncryption 286277 89.9207 sha256WithRSAEncryption 32146 10.0972 Certificate key size Count Percent -------------------------+---------+-------- ECDSA 384 2 0.0006 RSA 1024 1935 0.6078 RSA 2028 1 0.0003 RSA 2047 2 0.0006 RSA 2048 304898 95.7696 RSA 2049 2 0.0006 RSA 2056 3 0.0009 RSA 2058 1 0.0003 RSA 2060 1 0.0003 RSA 2064 1 0.0003 RSA 2080 3 0.0009 RSA 2084 4 0.0013 RSA 2345 1 0.0003 RSA 2408 1 0.0003 RSA 2432 60 0.0188 RSA 2536 1 0.0003 RSA 2612 1 0.0003 RSA 3000 1 0.0003 RSA 3050 1 0.0003 RSA 3072 19 0.006 RSA 3248 3 0.0009 RSA 3600 1 0.0003 RSA 4042 1 0.0003 RSA 4046 1 0.0003 RSA 4048 1 0.0003 RSA 4069 1 0.0003 RSA 4086 1 0.0003 RSA 4092 2 0.0006 RSA 4096 11427 3.5893 RSA 4098 1 0.0003 RSA 4192 2 0.0006 RSA 8192 3 0.0009 RSA/ECDSA Dual Stack 0 0.0 Supported Protocols Count Percent -------------------------+---------+------- SSL2 621 0.1951 SSL2 Only 73 0.0229 SSL3 314763 98.8683 SSL3 Only 3524 1.1069 SSL3 or TLS1 Only 140708 44.1969 TLS1 314191 98.6886 TLS1 Only 1117 0.3509 TLS1.1 164225 51.5837 TLS1.1 Only 8 0.0025 TLS1.1 or up Only 68 0.0214 TLS1.2 173049 54.3554 TLS1.2 Only 48 0.0151 TLS1.2, 1.0 but not 1.1 12720 3.9954 Scan performed between 7th and 15th of May 2014, full results available upon request - 45MiB xz tarball. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hkario(a)redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

2 3

Need help building updated version (1.0.0m) of OpenSSL for FC16
by Bernal, Daniel L 23 Jun '14

23 Jun '14

Hi. Can someone please point me in the right direction on how to build an updated version (1.0.0m) of openssl for FC16? I am looking to update a platform from the currently installed 1.0.0j version and having issues building an compatible versions. I can easily download, configure, build, and test the 1.0.0m source package from openssl.org but doing the install is where I have an issue. I can follow the openssl instructions and perform a "make install" but this does not update the repo database and does not clean up the previous version installed files. The right solution would be to install an upgraded version of the openssl and openssl-dev packages. I have created these but the files packaged are in different locations than the currently installed (1.0.0j) version. I also downloaded and built packages from the 1.0.0j version and these packages don't match what is installed by the 1.0.0j version on my FC16 system. This leads me to believe that the spec file used to build the FC16 1.0.0j version is special/different for some reason. Any advice/direction is greatly appreciated. Thanks, Daniel Daniel Bernal Software Platform Application Engineer SBD Segment Intel - Chandler, AZ * Direct: +1 480 5522289 * Mobile: +1 480 3192931 * Daniel.L.Bernal(a)intel.com<mailto:Daniel.L.Bernal@intel.com>

2 1

question about audit _by default_ in Fedora cloud images
by Matthew Miller 23 Jun '14

23 Jun '14

I was looking at https://fedorahosted.org/fesco/ticket/1311, and it occured to me that we don't ship the selinux troubleshooting tools by default in the minimal cloud image (add 'em if you need them). We do leave _audit_ there. What do people think about removing it? (As noted in the ticket, it's mostly useful with configuration, not in the default state.) -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

3 2

Re: [sparks@fedoraproject.org: Re: Reviewing/editing VPN information]
by Nikos Mavrogiannopoulos 20 Jun '14

20 Jun '14

On Thu, 2014-06-19 at 15:08 -0400, Paul Wouters wrote: > openconnect is for Cisco SSL clients - not something people will want to deploy unless they run Cisco (and then they should still prefer IPsec) Not any more. Openconnect is available both as client and server in Fedora. It is compatible with CISCO servers (and clients respectively), but there is no requirement whatsoever to use them. > openvpn is a nice alternative (although IMHO, mostly to avoid IPsec/IKE firewall rules. The often claimed "easier to setup" is simply not true) The same is true for openconnect, and it is based on TLS and Datagram TLS instead of a custom protocol. regards, Nikos

1 0

Re: Reviewing/editing VPN information
by Hal Murray 18 Jun '14

18 Jun '14

nmav(a)redhat.com said: > Maybe then it makes sense to combine descriptions for the VPN to a simple > reference on how to install the required packages and open the network > manager VPN menu. After that most things are straight forward and putting > more details will more likely make them irrelevant on the next release. If the goal is security, I think it helps to have an overview of what's going on and/or links to that sort of description. Are there common weaknesses? Common errors users make in setup? What data is encrypted? What needs to be kept secret? The Wikipedia page(s) may be good enough. But there are several that look interesting so it probably takes a few words to say which ones are important and why. NPR/Ars-Technica had an interesting story recently: Project Eavesdrop: An Experiment At Monitoring My Home Office http://tinyurl.com/qeop4z3 http://www.npr.org/blogs/alltechconsidered/2014/06/10/320347267/project-eav… rop-an-experiment-at-monitoring-my-home-office Ars tests Internet surveillance--by spying on an NPR reporter A week spent playing NSA reveals just how much data we leak online. http://tinyurl.com/ovt6y4j http://arstechnica.com/security/2014/06/what-the-nsa-or-anyone-can-learn-ab… -you-from-internet-traffic/ -- These are my opinions. I hate spam.

1 0

Re: Reviewing/editing VPN information
by Eric Christensen 18 Jun '14

18 Jun '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Tue, Jun 17, 2014 at 10:02:28AM +0200, Nikos Mavrogiannopoulos wrote: > On Mon, 2014-06-16 at 15:41 -0400, Eric H. Christensen wrote: > > On Mon, Jun 16, 2014 at 03:56:41PM +0200, Nikos Mavrogiannopoulos wrote: > > > On Wed, 2014-06-11 at 15:40 -0400, Eric H. Christensen wrote: > > > > I'm reviewing the VPN section of the Fedora Security Guide and I really... dislike what I'm seeing. The information in there is old and seems to focus on IPSec where we also now support things like OpenVPN, openconnect, vpnc, and PPTP. I'd really appreciate some help with this. If anyone would like to write, edit, or review what's there please let me know. > > > > > > These two patches clean-up a bit the introduction and add a section of > > > openconnect. > > > > Thank you! > > btw. Note that the IPSec section is outdated, and I'm pretty sure that > most of the commands listed there don't work. I don't use IPSec and > don't know how to correctly update it, but just to let you know. Yeah, I'm going to just remove all the IPSec stuff from the guide. If someone really wants it they can come back in and rewrite it correctly. - -- Eric - -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security sparks(a)redhat.com - sparks(a)fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBCgAGBQJToEk4AAoJEB/kgVGp2CYv1D4MAJVXBJ1bpyDt4fDQUEPAwK1c 9Kb/CrdENP1Wlw0MMrs34v7IMot/rvCK+MVjRr4WOEKITccV3x5KFeZiKHmU/NhF JfXGTXrhie5itF02Dtpa2tUIR7bYZy4rEs3qdsTB9ZkJFo6Jfl6yUPEEvF2qFXpw N9UEK1dkvW788CUfUeIQFIuc7PxwYNH6uZIu4arp7mgLiXifsMYnsMSSwD/BvNO+ i+SPMgtAIx/6wUHLAvzAytaKXQE/Cze0NWR9/zye551WKTH4RajEWaHR9rjReYCz fU75H8JPCz/X5v3SXB0A779/AhQdFmiHEHCiws939EQlVDMnnKZm+hNA8A9nYje9 7AQ1xr4HFW4p07BEmZPmKj+y1AAMSJzoAUJCbrgm/n3bY/QSvPE5/SUlZkO2hJLG luhm3wyfYgmJKFftoELICMU26pj/0mqcMhMoMuhDu+DqOR3IqUpvb8kC1HTEG7IP PwUzo6OEY87yL8qUVuGpPMC+TcKEz2D7yWgsWoGOJg== =fQjW -----END PGP SIGNATURE-----

2 1

Auditing the Fedora Security Guide
by Eric Christensen 17 Jun '14

17 Jun '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 It’s been a while since anyone has really gone through the Fedora Security Guide. In the few places I’ve poked at I’ve found a massive build-up of… old stuff. I’m quite sure that many of those commands don’t do what is said here any longer. There are ~50 files that need to be looked at to make sure that the information is current and actually tells people the proper thing to do to secure their Linux system. In support of this mission (that I hope to complete before the release of Fedora 21) I’ve created a wiki page[0] that outlines the goals, explains how to help, and lists the pages that need to be audited and/or updated. I’d appreciate some assistance if only to have more eyes looking over the pages and making comments on the wiki about things that need to be fixed. [0] https://fedoraproject.org/wiki/Security_Guide_Audit - -- Eric - -------------------------------------------------- Eric "Sparks" Christensen Fedora Project sparks(a)fedoraproject.org - sparks(a)redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBCgAGBQJToGPSAAoJEB/kgVGp2CYvIkIL/01wEQHWbPFcag1btF/iB7pd rvkda3QHzjKdnvUf7Y8OoP1xe7R0qYj9/SIF6vm/3ClTWCXzRybHT/r8uU6eEtEQ VdACSTae1LXUW/VphZ+kXgIphcCFjdOT/N1pLA+dWkhpzkPz4FO3lSWZT01BwU7b bFMd/gCQuPFnf9kSVC1mYkkiKR9Epyvww96me7ackmqWPI+dBspdd3kRiSpM1Y89 NSJw2nSYP/JejH7YNy8uO4TA5diZu64+I2KWpP3lGHdp/ySOJZgOjloSXP01C/t9 IHMS18Nj4OR3hAJvDtD6eWtODSg3ZHwSmJSa3bo86RR1mNeL5L11rbue9Nu5nwK0 Q5Treame4Mpqad9KKtE9F62HYN0FIr1KioNaLgO6kdrWQAzAPn3doCDGa9KF17zg criyrh03BONLiLOenlxY5o8OXU9oMZ2szcq1Epmsr+7NM3SxHtCPZAhqu9IE2I9B GRMJkUwoTrY6XRUsKpOtbAL09AhRScPCkvSimbiorw== =RucH -----END PGP SIGNATURE-----

1 0

Reviewing/editing VPN information
by Eric Christensen 16 Jun '14

16 Jun '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I'm reviewing the VPN section of the Fedora Security Guide and I really... dislike what I'm seeing. The information in there is old and seems to focus on IPSec where we also now support things like OpenVPN, openconnect, vpnc, and PPTP. I'd really appreciate some help with this. If anyone would like to write, edit, or review what's there please let me know. Thanks! - -- Eric - -------------------------------------------------- Eric "Sparks" Christensen Fedora Project sparks(a)fedoraproject.org - sparks(a)redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBCgAGBQJTmLC1AAoJEB/kgVGp2CYvoxcL/3U8eNrX8xoqif6rYlagk2ee yUGphiTY/WkDV3Ade8fpgDDjBmjXXgj2gbO9JguPK/CSAuJZO3jNhIl2Z35l/Suz IKkqyeVIPLduKJKs7TNalUTkmKSPg5JHT5tyBhg04dLpvvwRFbRgm1WiSA7GpDYu 1ewuDjhCSFazF+d2vyZSznrmv0YOjM4+raDnT3OKkQmrWtoqv7tfoWKF8sX7O8xa wUz5RU3UXwoSwxX0XUJyrCUHqU6mFVryZjni70gQT2TA65t4ghaEwlEAIrffUHbN EX1g875WNzJUQ2NqP0ugPED3tKnWUjXf0G74Qyybk5dl6LaSH3O62WICwUyEakCX sOmPZ0Z8u5rTTYRmsjOvB+XLmVc1t59mBMYzFkkHNU9cs1E69oyLNUdlwm9XyG7e 5ehRO7vBAOSqT3dX85oRKci2gAq92GnsrwDG+VVoKVSngTO740CuTh669NsDbU39 0YR0VBT9UkLQcJs7AHzsL0HgnpXbeu5P/dKuFF8gng== =JiKL -----END PGP SIGNATURE-----

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

security June 2014