What is Mutual TLS (mTLS)?

Mutual Transport Layer Security (#mTLS) establishes an encrypted TLS connection in which both parties use X.509 digital certificates to authenticate and verify each other. MTLS can help mitigate the risk of moving services to the cloud, and prevent malicious third parties from imitating genuine apps. So, let’s start the clock for What is mTLS?

Read the Article on F5 Labs.

Not only does F5 Labs provide freely available Threat Intelligence, they also have an Educational series covering many types of attacks, threats, and essential security concepts. If you are getting started in cyber security or there’s always been that one topic you’ve never quite understood, #F5Labs will help you learn the basics.

TLS 1.3 Enterprise Adoption

With the new TLS 1.3 specification published by the IETF in August 2018, many organizations are adopting plans for the new specification. F5, together with Enterprise Management Associates, conducted research to better understand how enterprises are impacted by the growing use of encryption.

Get your copy today at: https://interact.f5.com/TLS-13-adoption-in-enterprise.html

 

ps

SSL Visibility with SSL Orchestrator

Are You Equipped to Decrypt?

Over 80% of page loads are encrypted with SSL/TLS and Attackers commonly use encryption to hide malicious payloads. If you’re not inspecting SSL/TLS traffic, you will miss attacks, and leave your organization vulnerable. I light up how SSL Orchestrator provides robust decryption/encryption of SSL/TLS traffic.



ps

Post of the Week: SSL on a Virtual Server

In this Lightboard Post of the Week, I answer a few questions about SSL/https on Virtual Servers. BIG-IP being a default deny, full proxy device, it's important to configure specific ports, like 443, to accept https traffic along with client and server side profiles and include your SSL certificates. We cover things like SAN/SNI certificates but I failed to mention that self-signed certificates are bad anywhere except for testing or on the server side of the connection.



Thanks to DevCentral members, testimony, Only1masterblaster, Faruk AYDIN, MrPlastic, Tyler G, Prince, and dward for their Q/A engagement.

Posted Questions on DevCentral:

• https on virtual server
• LINKING SSL CERTIFICATE TO A VIRTUAL SERVER
• SSL CERTIFICATE KEY
• Maximum number of client SSL profiles per virtual server?
• Need to support thousands of unique SSL certificates on a single VIP

ps

Your SSL Secrets Uncovered

Get Started with SSL Orchestrator

SSL and its brethren TLS is becoming more prevalent to secure IP communications on the internet. It’s not just financial, health care or other sensitive sites, even search engines routinely use the encryption protocol. This can be good or bad. Good, in that all communications are scrambled from prying eyes but potentially hazardous if attackers are hiding malware inside encrypted traffic. If the traffic is encrypted and simply passed through, inspection engines are unable to intercept that traffic for a closer look like they can with clear text communications. The entire ‘defense-in-depth’ strategy with IPS systems and NGFWs lose effectiveness.

F5 BIG-IP can solve these SSL/TSL challenges with an advanced threat protection system that enables organizations to decrypt encrypted traffic within the enterprise boundaries, send to an inspection engine, and gain visibility into outbound encrypted communications to identify and block zero-day exploits. In this case, only the interesting traffic is decrypted for inspection, not all of the wire traffic, thereby conserving processing resources of the inspecting device. You can dynamically chain services based on a context-based policy to efficiently deploy security.

This solution is supported across the existing F5 BIG-IP v12 family of products with F5 SSL Orchestrator and is integrated with such solutions like FireEye NX, Cisco ASA FirePOWER and Symantec DLP.

Here I’ll show you how to complete the initial setup.

A few things to know prior – from a licensing perspective, The F5 SSL visibility solution can be deployed using either the BIG-IP system or the purpose built SSL Orchestrator platform. Both have same SSL intercept capabilities with different licensing requirements.

To deploy using BIG-IP, you’ll need BIG-IP LTM for SSL offload, traffic steering, and load balancing and the SSL forward proxy for outbound SSL visibility. Optionally, you can also consider the URL filtering subscription to enforce corporate web use policies and/or the IP Intelligence subscription for reputation based web blocking. For the purpose built solution, all you’ll need is the F5 Security SSL Orchestrator hardware appliance.

The initial setup addresses URL filtering, SSL bypass, and the F5 iApps template.

URL filtering allows you to select specific URL categories that should bypass SSL decryption. Normally this is done for concerns over user privacy or for categories that contain items (such as software update tools) that may rely on specific SSL certificates to be presented as part of a verification process.

Before configuring URL filtering, we recommend updating the URL database. This must be performed from the BIG-IP system command line. Make sure you can reach download.websense.com on port 80 via the BIG-IP system and from the BIG-IP LTM command line, type the following commands:

modify sys url-db download-schedule urldb download-now false modify sys url-db download-schedule urldb download-now true

To list all the supported URL categories by the BIG-IP system, run the following command:

tmsh list sys url-db url-category | grep url-category

Next, you’ll want to configure data groups for SSL bypass. You can choose to exempt SSL offloading based on various parameters like source IP address, destination IP address, subnet, hostname, protocol, URL category, IP intelligence category, and IP geolocation. This is achieved by configuring the SSL bypass in the iApps template calling the data groups in the TCP service chain classifier rules. A data group is a simple group of related elements, represented as key value pairs. The following example provides configuration steps for creating a URL category data group to bypass HTTPS traffic of financial websites. 

For the BIG-IP system deployment, download the latest release of the iApps template and import to the BIG-IP system.

Extract (unzip) the ssl-intercept-12.1.0-1.5.7.zip template (or any newer version available) and follow the steps to import to the BIG-IP web configuration utility.

From there, you’ll configure your unique inspection engine along with simply following the BIG-IP admin UI with the iApp questionnaire. You’ll need to select and/or fill in different values in the wizard to enable the SSL orchestration functionality. We have deployment guides for the detailed specifics and from there, you’ll be able to send your now unencrypted traffic to your inspection engine for a more secure network.

ps

Resources:

• Ponemon Report: Application Security in the Changing Risk Landscape
• IDC Report: The Blind State of Rising SSL Traffic

Ask the Expert – Why SSL Everywhere?

Kevin Stewart, Security Solution Architect, talks about the paradigm shift in the way we think about IT network services, particularly SSL and encryption. Gone are the days where clear text roams freely on the internal network and organizations are looking to bring SSL all the way to the application, which brings complexity. Kevin explains some of the challenges of encrypting all the way to the application and ways to solve this increasing trend. SSL is not just about protecting data in motion, it’s also about privacy.

ps

Related:

• Ask the Expert – Are WAFs Dead?
• RSA2015 – SSL Everywhere (feat Holmes)
• AWS re:Invent 2015 – SSL Everywhere…Including the Cloud (feat Stanley)
• F5 SSL Everywhere Solutions

Technorati Tags: f5,ssl,encryption,pki,big-ip,security,privacy,silva,video

Connect with Peter:	Connect with F5:

AWS re:Invent 2015 – SSL Everywhere…Including the Cloud (feat Stanley)

Thomas Stanley, Product Management Engineer, discusses the challenges organizations face when implementing a SSL Everywhere strategy even in the cloud. He gets into areas like SSL certificates, key management, multiple interfaces and the learning curves involved with deploying SSL Everywhere. He explains F5’s role in SSL management, how certificates move with configurations and how this central point of control makes SSL Everywhere easy, especially for cloud applications.

ps

Related:

• AWS re:Invent 2015 – The Preview Video
• Find F5 at AWS re:Invent 2015
• AWS re:Invent 2015 - Value of App Services in the Cloud (feat Vrankic)
• What are ‘Critical app Services’ and why do you need them?
• F5 at AWS re:Invent

Technorati Tags: f5,aws,amazon,re:invent,cloud,ssl,app services,silva,video,security

Connect with Peter:	Connect with F5:

RSA2015 – SSL Everywhere (feat Holmes)

F5 Worldwide Security Evangelist, David Holmes, talks about why the internet is going SSL Everywhere. He explains why there’s been a surge in encrypted traffic and reveals some interesting statistics from his ongoing research on the SSL protocol. Always an engaging guest, David takes us through Forward Secrecy, Strict Transport Security and SSL v3. What they solve and how they are being used in the wild.

 

ps

Related

• RSA 2015 - The Preview Video
• RSA2015 – Find F5
• RSA2015 Partner Spotlight - RSA Risk Based Authentication
• RSA2015 – Defending the New Perimeter
• RSA2015 – The InfoSec Landscape with Jeremiah Grossman
• RSA2015 Partner Spotlight: FireEye Integration
• F5 @ RSA 2015
• F5 YouTube Channel

Technorati Tags: f5,rsa,rsac,security,ssl,encryption,stats,holmes,silva,video

Connect with Peter:	Connect with F5:

RSA2013: BIG-IP SSL/TLS Services

I give up the mic to F5 Product Marketing Manager, Danny Luedke who promptly whiteboards his way through the many BIG-IP solutions to handle SSL/TLS. Certificate management, encryption, performance and other goodies are discussed.

 

ps

Related:

• RSA2013: Aloha from RSA
• RSA2013: Find F5
• RSA2013: Gimme 90 Seconds Security Edition
• RSA2013: Partner Spotlight – Websense
• RSA2013: Partner Spotlight – Quarri
• RSA2013: F5 RSA Security Trends Survey
• F5′s YouTube Channel
• In 5 Minutes or Less Series (23 videos – over 2 hours of In 5 Fun)
• Inside Look Series
• Life@F5
• Also this week, check out: Mobile World Congress – Day 1 & Mobile World Congress – Day 2

Technorati Tags: f5,rsac,rsa,rsa2013,psilva,video,ssl/tls

Pulse2012 - BIG-IP SSL Offload

I meet again with F5 Solution Engineer Nojan Moshiri to talk about SSL Offload, it's benefits to Maximo and how easy it is to configure on the BIG-IP.  SSL Offload in 3 Easy Steps.

Pulse2012 - BIG-IP SSL Offload

ps

Resources:

• Pulse2012 - Find F5 Booth E404
• Pulse2012 - F5 Solutions for IBM
• Pulse2012 - How F5 Optimizes IBM Solutions
• Pulse2012 - BIG-IP SSL Offload
• Optimizing IBM Tivoli Maximo Deployments
• Building an Enterprise Cloud with F5 and IBM
• Bursting to the IBM SmartCloud
• Solutions for IBM applications
• IBM Pulse 2012: Optimizing the World's Infrastructure
• F5 YouTube Channel

Technorati Tags: F5, video, Pete Silva, security, business, education, ssl offload, pulse, ibm, tivoli, Maximo

Connect with Peter:	Connect with F5:

The New Certificate 2048 My Performance

SSL is a cryptographic protocol used to secure communications over the internet.  SSL ensures secure end-to-end transmission and is implemented in every Web browser.  It can also be used to secure email, instant messaging and VoIP sessions.  The encryption and decryption of SSL is computationally intensive and can put a strain on server resources like CPU.  Currently, most server SSL Certificates are 1024-bit key length and the National Institute of Standards and Technology (NIST) is recommending a transition to 2048-bit key lengths by Jan 1^st 2011.

SSL and its brethren, TLS (Transport Layer Security) provide the security and encryption necessary for secure communications over the internet, and particularly for creating an encrypted link between the browser and web server.  You will see ‘https’ in your browser address bar when visiting a site that is SSL enabled.  The strength of SSL is tied to the size of the Public Key Infrastructure (PKI) key.  Key length or key size (1024 bit, 2048 bit, 4092 bit) is measured in bits and typically used to indicate the strength of the encryption algorithm; the longer the key length, the harder it is decode.  In order to enable an SSL connection, the server needs to have a digital certificate installed.  If you have multiple servers, each requiring SSL, then each server must have a digital certificate.


Transactions handled over SSL can require substantial computational power to establish the connection (handshake) and then to encrypt and decrypt the transferred data.  If you need the same performance as non-secured data, then additional computing power (CPU) is needed.  SSL processing can be up to 5 times more computationally expensive than clear text to have the same level of performance, no matter which vendor is providing the hardware.  This can have significant, detrimental ramifications to server performance.  SSL Offload takes much of that computing burden off the servers and places it on dedicated SSL hardware.  SSL offload allows organizations to migrate 100% of their communications to SSL for greater security, consolidation of certificates, centralized management, and reduction of cost and allows for selective content encryption & encrypted cookies along with the ability to inspect and modify encrypted traffic.  SSL offloading can relieve the Web server of the processing burden of encrypting and/or decrypting traffic sent via SSL.

Customers, vendors and the industry as a whole will soon face the challenge of what to do regarding their SSL strategy.  Those who have valid 1024-bit certificates need to understand the ramifications of the switch and that next time they go to renew their certificates, they will be forced to buy 2048-bit certificates.  This will drastically affect their SSL capacity on both the servers and the load balancer.  There is a significant increase in needed computational power going from 1024-bit to 2048-bit and an exponential drop off in performance when doubling key sizes regardless of the platform or vendor.  Most CAs, like Entrust have already stopped issuing 1024-bit certificates, and Verisign will stop doing so in 4-5 months. Since many certificate vendors are now only issuing 2048-bit certificates, customers might not understand the potential SSL performance capacity.  The overall performance impact of 2048-bit keys on the servers if you don’t offload will increase significantly.  This can be a challenge when you have hundreds of servers providing content

Existing certificates issued with 1024-bit encryption will not stop working.  If you still have valid certificates but need to ensure you are delivering 2048-bit certificates to users (or due to regulatory requirements), one option, as mentioned in Lori’s blog, is to install the 2048-bit certificate on your BIG-IP LTM for the off-load performance capabilities and then use your existing 1024-bit keys from BIG-IP LTM to the back-end server farm.  Simply import the server certificates directly into BIG-IP.  This means that the SSL Certificates that would normally go on each server can be centrally stored and managed by LTM, thereby reducing the cost of the certificates needed as well as the cost for any specialized server software/hardware required.  This keeps the load off the servers, potentially eliminating any performance issues and allows you to stay current with NIST guidelines while still providing an end to end SSL connection for your web applications.  This is a huge advantage over commodity hardware with no SSL offload capabilities.  BIG-IP LTM has specialized SSL chips which are dedicated and optimized for SSL encryption and decryption.  These chips provide the ability to maintain performance levels even at longer key lengths, whereas in commodity hardware the computational load of SSL decreases the overall system performance impacting user experience and other server tasks.


The F5 SSL Acceleration Module removes all the bottlenecks for secure, wire-speed processing, including concurrent users, bulk throughput, and new transactions per second along with supporting certificates up to 4092-bits.  The fully loaded F5 VIPRION chassis is the most powerful SSL-offloading engine on the market today and, along with the BIG-IP LTM Virtual Edition (VE), provides a powerful solution to the SSL challenge.  By front-ending BIG-IP VE farms with a VIPRION, you can assign load balancing or SSL offloading to a dedicated ADC.  The same approach can remedy access to legacy systems that might not support 2048-bit certificates or cannot be upgraded due to business restrictions or other rationale.  By deploying an F5 BIG-IP device with 2048k certificate in front of the legacy systems, back-end encryption can be accomplished using existing 1024-bit certificates.  F5 does support 4096-bit keys, future-proofing support for longer keys down the road and offers backwards and forwards compatibility but unless there is a strong business case, 2048-bit keys are recommended for optimal performance and protection.

ps

Related:

• F5 Friday: The 2048-bit Keys to the Kingdom
• 2048-bit Infrastructure Impact Reporting Tool
• Changing LTM Device Certificate from 1024 -> 2048 key
• BIG-IP LTM
• F5 SSL Acceleration
• National Institute of Standards and Technology

Technorati Tags: F5, infrastructure 2.0, integration, cloud computing, Pete Silva, security, business, education, technology, application delivery, cloud, context-aware, infrastructure 2.0, web, internet

twitter: @psilvas

In 5 Minutes Video - Smart Connection with the BIG-IP Edge Client

Watch how the F5 Networks BIG-IP Edge Client solution gets you connected automatically when you boot/start up your computer along with seeing browser based access of the F5 BIG-IP Edge Gateway.

ps

Technorati Tags: Pete Silva,F5,security,application security,network security, business, banks, education, technology, social networking, webinar, video

It all comes down to YOU - The User

One of my favorite Security writers, Bruce Schneier, had an interesting entry last week called Reacting to Security Vulnerabilities where he discusses the recent reports about the security flaw in the SSL protocol and how we as users should relax and essentially, ‘do nothing.’  “What?!? – Do nothing??”  Yup, and he has some good reasons why.  Usually, new exploits, threats, breaches and the typical security stuff that garners the headlines, makes security folks jump.  Jump to search the internet for anything related, jump to see if our systems are infected or vulnerable, jump to put an action plan in place to reduce the risk.  These are reactionary behaviors when gloom gets delivered and we fully don’t understand the risk.  I’m not saying ignore warnings or plan for the worst, but since several new ‘weaknesses’ seem to get published on a monthly basis, you do need to prioritize and put some context around it.

With anything in life, there are certain things we have control over and others we do not.  For many years now, we’ve been warned that it is risky to click on embedded links in a suspicious email or dangerous to click through the certificate warnings from your browser and hopefully many people have changed their behavior.  That’s within our control.  But when a researcher finds a specific vulnerability in a particular protocol, potentially affecting several vendors, there is really not much an individual user can do.  Sure, you or the IT department can check with their vendor to see if it applies to their product but would you immediately stop using something when it’s a critical part of your infrastructure.  Once again, which is usually the case for security, you must weigh the risks and determine if it’s within your control.  Bruce points out that many of the vulnerabilities affect systems that are out of our control and if your data is already out there, unplugging your computer will not lessen the potential exposure.

What you can do is simply stick to your general security practices (AV/FW, OS patch, Auto updates, backups, common sense), which already protect you from a slew vulnerabilities but let the experts/vendors figure out the best way to handle new exposure(s) since they must deal with them on a daily basis.  If the risk is too great and your infrastructure is vulnerable, push your vendor for an answer.  Most vendors, especially with security products, are fairly reasonable and typically move fast when it comes to security holes – their reputation and revenue are at risk.  You can also report to CERT if you’re not getting a response but most vulnerability ‘finders’ alert the vendor fist and give them a chance to fix or respond to it.

Protecting yourself from the multitude of threats on the internet can be daunting, never ending, and always changing so you do need to be vigilant with the things you can control but as you peruse the Top 9 Beaches of 2009 or the Top 15 Most Common Attacks, you find there was/is little you could do to avoid them.
ps

• #25 out of 26 Short Topics about Security
• Previous stories: 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13.5, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1

*For the record, F5 is listed on the US-CERT site as being potentially vulnerable but we have tested our products/versions and are not vulnerable to this issue.  F5 Networks has published a security advisory in the past to cover similar vulnerability and provide best practice recommendations. These best practice recommendations can be found at the F5 support site:
https://support.f5.com/kb/en-us/solutions/public/6000/900/sol6999.html
https://support.f5.com/kb/en-us/solutions/public/10000/700/sol10737.html