<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>TLS (Transport Layer Security) on Rietta Cybersecurity</title>
    <link>https://rietta.com/glossary/tls/</link>
    <description>Recent content in TLS (Transport Layer Security) on Rietta Cybersecurity</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <copyright>1999-2026 Rietta Inc. All Rights Reserved.</copyright>
    <lastBuildDate>Fri, 16 Oct 2026 10:35:25 -0400</lastBuildDate>
    <atom:link href="https://rietta.com/glossary/tls/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Is Ruby on Rails Secure?</title>
      <link>https://rietta.com/learning/appsec/is-ruby-on-rails-secure/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://rietta.com/learning/appsec/is-ruby-on-rails-secure/</guid>
      <description>Question: Is Ruby on Rails secure? What if I add SSL?&#xA;Answer: Security is not an on/off switch. You need to ask three questions whenever you&amp;rsquo;re trying to determine the appropriate security level for anything:&#xA;Secure against what? What is the worst thing that can happen? Compared to what alternative? There is no secure switch to make all the risks go away. Security is a process that includes every aspect of the business model, application development, and deployment management practices, not a single magic setting.</description>
    </item>
    <item>
      <title>Generate OpenSSL Elliptic Curve Key Pair from the Command Line</title>
      <link>https://rietta.com/blog/openssl-generating-ec-key-from-command/</link>
      <pubDate>Tue, 18 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://rietta.com/blog/openssl-generating-ec-key-from-command/</guid>
      <description>&lt;p&gt;Back in 2012, I wrote &lt;a href=&#34;https://rietta.com/blog/openssl-generating-rsa-key-from-command/&#34;&gt;Generate OpenSSL RSA Key Pair from the Command Line&lt;/a&gt;, which has gone on to become the single most-visited post on this entire blog. Fourteen years is a long run for a command-line tutorial, and RSA hasn&amp;rsquo;t gone anywhere. But if you&amp;rsquo;re generating a new key pair in 2026, I&amp;rsquo;d point you toward elliptic curve cryptography (ECC) instead of a bigger RSA key.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Shorter SSL/TLS Lifetimes: Business Impact of Monthly Certificate Renewals</title>
      <link>https://rietta.com/blog/shorter-tls-lifetimes-business-impact-of-monthly-renewals/</link>
      <pubDate>Tue, 22 Apr 2025 08:00:00 +0000</pubDate>
      <guid>https://rietta.com/blog/shorter-tls-lifetimes-business-impact-of-monthly-renewals/</guid>
      <description>The CA/Browser forum has reportedly approved a measure to reduce the allowed time for certificate validity from 398 to 47 days by March 15, 2029. This change will require users to renew certificates on a nearly monthly basis. This is a manual process that will now have to be done up to 10 times per year, instead of just once. This change will not be evident to most Internet users and businesses.</description>
    </item>
    <item>
      <title>Xfinity is Man-in-the-Middle (MITM) Attacking my Internet</title>
      <link>https://rietta.com/blog/comcast-insecure-injection/</link>
      <pubDate>Tue, 29 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://rietta.com/blog/comcast-insecure-injection/</guid>
      <description>I recently moved to Fort Collins, CO. With this move also meant new internet&amp;hellip; Unfortunately, Xfinity (Comcast) is the only ISP available in the area until early next year, so I purchased service through Xfinity. I had heard horror stories from co-workers about Comcast, but after working at a company that makes billing and networking software and hardware for Wireless Internet Service Providers, I was skeptical; everyone seems to hate their ISP.</description>
    </item>
    <item>
      <title>Security Quick-Wins: Use DNS CAA records to avoid fraudulent certificates</title>
      <link>https://rietta.com/blog/security-quick-wins-use-dns-caa-records-to-avoid-fraudulent-certificates/</link>
      <pubDate>Tue, 24 Jul 2018 11:30:00 -0500</pubDate>
      <guid>https://rietta.com/blog/security-quick-wins-use-dns-caa-records-to-avoid-fraudulent-certificates/</guid>
      <description>&lt;p&gt;It&amp;rsquo;s ordinarily possible for a &lt;abbr title=&#34;Certificate Authority&#34;&gt;CA&lt;/abbr&gt; to&#xA;sign a certificate for your domain without properly validating it. We&#xA;essentially have to trust them to take security seriously and to not make&#xA;mistakes in their process.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Migrate Away from SSL/Early TLS for PCI Compliance</title>
      <link>https://rietta.com/blog/migrate-away-from-ssl-early-tls-for-pci-compliance/</link>
      <pubDate>Sat, 30 Jun 2018 19:00:00 -0500</pubDate>
      <guid>https://rietta.com/blog/migrate-away-from-ssl-early-tls-for-pci-compliance/</guid>
      <description>&lt;p&gt;Systems that handle payment information, particularly e-commerce systems, are&#xA;regulated by PCI DSS. Changes to the PCI compliance requirements have&#xA;reclassified the use of outdated and insecure versions of TLS (and its&#xA;predecessor, SSL) as non-compliant. This has some significant impact across the&#xA;software industry as the changes went into enforcement today, June 30, 2018. The&#xA;key takeaways for us as web application developers are that we must ensure that&#xA;our deployed systems are using modern and secure TLS configurations, and that we&#xA;should now do so at the expense of supporting legacy web browsers that are&#xA;non-compliant, namely old versions of Internet Explorer and Windows.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Equifax Missed Defense in Depth, Allowing a Massive Data Breach</title>
      <link>https://rietta.com/blog/equifax-defense-in-depth/</link>
      <pubDate>Mon, 18 Sep 2017 00:00:00 -0400</pubDate>
      <guid>https://rietta.com/blog/equifax-defense-in-depth/</guid>
      <description>&lt;p&gt;Equifax has confirmed that the main vector that lead to the data breach was a remote code execution vulnerability in Apache Struts that had been known for months [&lt;a href=&#34;https://rietta.com/blog/equifax-defense-in-depth/#equifax-announcement&#34;&gt;1&lt;/a&gt;]. Equifax had not yet patched it within the production environment. This is not just a lesson in the importance of patch management but one of defense in depth. The weakness in Equifax&amp;rsquo;s design was set in motion years before when they failed to design with the assumption that the front-end web server would be compromised.&lt;/p&gt;&#xA;&lt;p&gt;The attacker was able to obtain the massive trove of private data because the web application was the only gatekeeper. Once the remote code execution vulnerability was exploited, the attacker was able to access data unfettered by additional access controls.  Equifax chose to use a typical web application architecture without defense in depth.&lt;/p&gt;&#xA;&lt;p&gt;Defense in depth has to start as part of the development process. All developers should be aware of the OWASP Top 10 (&lt;a href=&#34;https://rietta.com/blog/equifax-defense-in-depth/#owasp-top10&#34;&gt;#3&lt;/a&gt;) and their work should be audited against the OWASP Advanced Security Verification Standard (ASVS) [&lt;a href=&#34;https://rietta.com/blog/equifax-defense-in-depth/#owasp-asvs&#34;&gt;#3&lt;/a&gt;] for the level appropriate for the risk faced by an organization in the event of a security breach.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How To Protect Against the POODLE SSLv3 Vulnerability</title>
      <link>https://rietta.com/blog/how-to-protect-against-the-poodle-sslv3-vulnerability/</link>
      <pubDate>Thu, 16 Oct 2014 09:21:22 -0400</pubDate>
      <guid>https://rietta.com/blog/how-to-protect-against-the-poodle-sslv3-vulnerability/</guid>
      <description>&lt;p&gt;The &lt;acronym title=&#34;Padding Oracle On Downgraded Legacy&#xA;Encryption&#34;&gt;POODLE&lt;/acronym&gt; SSL vulnerability marks the third major security flaw discovered this year that impacts the security of millions of websites.&lt;/p&gt;&#xA;&lt;p&gt;The attack works by forcing the connection to downgrade from the newer TLS protocol to the 18 year old SSL 3 protocol, which is obsolete and insecure, and then utilizing a weakness to calculate small strings of data from the encrypted communication, such as session cookies.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Raspberry Pi crypto key management project!</title>
      <link>https://rietta.com/blog/raspberry-pi-crypto-project/</link>
      <pubDate>Thu, 02 Oct 2014 21:20:16 -0400</pubDate>
      <guid>https://rietta.com/blog/raspberry-pi-crypto-project/</guid>
      <description>&lt;p&gt;A few months ago I bought a &lt;a href=&#34;http://www.raspberrypi.org/&#34;&gt;Raspberry Pi B&lt;/a&gt; to experiment with, but sadly my day job as a Ruby developer keep me busy enough that it just sat on the shelf unused until this last weekend. For those not yet in the know, the Raspberry Pi is an excellent little complete computer system on a small circuit board that uses very low power and looks like this:&lt;/p&gt;&#xA;&lt;p&gt;&lt;img src=&#34;https://rietta.com/images/posts/2014/10/raspberry_pi_b_first_boot.jpg&#34; alt=&#34;My Raspberry Pi booting for the First Time!&#34; width=&#34;1280&#34; height=&#34;720&#34;&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>Free, Universal SSL with Cloudflare</title>
      <link>https://rietta.com/blog/universal-ssl-with-cloudflare/</link>
      <pubDate>Mon, 29 Sep 2014 09:11:52 -0400</pubDate>
      <guid>https://rietta.com/blog/universal-ssl-with-cloudflare/</guid>
      <description>&lt;p&gt;Cloudflare, the web application security forward proxy and transparent CDN service, has &lt;a href=&#34;https://blog.cloudflare.com/introducing-universal-ssl/&#34;&gt;announced on their blog universal SSL even on their free accounts&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;This is a very welcome development for the public interest on the internet.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Retake the Net for Privacy!</title>
      <link>https://rietta.com/blog/retake-the-net-for-privacy/</link>
      <pubDate>Thu, 05 Jun 2014 15:18:56 -0400</pubDate>
      <guid>https://rietta.com/blog/retake-the-net-for-privacy/</guid>
      <description>Rietta (@riettainc on Twitter) will educate customers on the use of strong headers, TLS w/ PFS, and other countermeasures as part of our continuing security initiatives program.&#xA;Will you also help join us in the world-wide cause to retake the net?&#xA;Check out the petition yourself at Reset the Net and choose for yourself today what you can personally do to make the web secure from illegitimate prying eyes.</description>
    </item>
    <item>
      <title>OpenSSL Vulnerability, Patch 1.0.1 Immediately</title>
      <link>https://rietta.com/blog/openssl-emergency/</link>
      <pubDate>Mon, 07 Apr 2014 23:50:50 -0400</pubDate>
      <guid>https://rietta.com/blog/openssl-emergency/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Major Vulnerability, Action Required.&lt;/strong&gt;  A major vulnerability for OpenSSL 1.0.1 was announced today, April 7, 2014.  &lt;a href=&#34;http://heartbleed.com/&#34;&gt;The Heartbleed Bug&lt;/a&gt;, &lt;a href=&#34;https://www.openssl.org/news/secadv_20140407.txt&#34;&gt;CVE-2014-0160&lt;/a&gt;, is a major vulnerability that may lead to &lt;strong&gt;secret key disclosure&lt;/strong&gt;.  A discussion of this vulnerability can be found on the &lt;a href=&#34;https://news.ycombinator.com/item?id=7548991&#34;&gt;Hacker News thread on the Heartbleed vulnerability&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Conditionally Including Resources on SSL or non-SSL to Avoid Mixed Content Security Warnings in Ruby on Rails</title>
      <link>https://rietta.com/blog/conditionally-including-resources-on/</link>
      <pubDate>Wed, 21 Dec 2011 00:00:00 +0000</pubDate>
      <guid>https://rietta.com/blog/conditionally-including-resources-on/</guid>
      <description>&lt;p&gt;When building content that can be delivered on an encrypted HTTPS connection it is necessary to reference all of the embedded resources, 3rd party badge images, embedded YouTube videos, etc, from an HTTPS url.  Otherwise a mixed content error will imply to your users that the website is not safe, ouch!&lt;/p&gt;</description>
    </item>
    <item>
      <title>Authentication Without Encryption for Ham Radio</title>
      <link>https://rietta.com/blog/authentication-without-encryption-for/</link>
      <pubDate>Mon, 17 Aug 2009 00:00:00 +0000</pubDate>
      <guid>https://rietta.com/blog/authentication-without-encryption-for/</guid>
      <description>In April 2004, I gave a talk for the Atlanta Radio Club about the possibilities for authenticated digital communication for amateur radio applications. I published the document on my Georgia Tech website at that time. Since I no longer have an account at Georgia Tech, I am re-posting the document here.&#xA;Authenticating on a Ham Internet The FCC regulations for amateur radio, part 97, rule that encryption cannot be used to obscure the meaning of communications.</description>
    </item>
  </channel>
</rss>
