main

Application DeliverySecuritySSL

Adopt TLS 1.3 – Kill Two Birds with One Stone

September 13, 2018 — by Prakash Sinha15

tls_1.3_ssl_blog_img-960x600.jpg

Transport Layer Security (TLS) version 1.3 provides significant business benefits by making applications more secure, improving performance and reducing latency for the client. Changes in how handshake between client and server is designed has decreased site latency – utilizing a faster handshake, and use of Elliptic Curve (EC) based ciphers that allow faster page load time. TLS 1.3 also enforces forward security to prevent a replay of all recorded data if private session keys are compromised.

Transport Level Security – A Quick Recap

Transport Layer Security (TLS) version 1.0, the first standardized version of SSL introduced in 1999, which is based on SSL v3.0. TLS 1.0 is obsolete and vulnerable to various security issues, such as downgrade attacks. Payment Card Industry (PCI) had set a migration deadline of June 30, 2018 to migrate to TLS 1.1 or higher.

TLS 1.1, introduced in 2006, is more secure than TLS 1.0 and protected against certain types of Cipher Block Chaining (CBC) attacks such as BEAST. Some TLS 1.1 implementations are vulnerable to POODLE, a form of downgrade attack. TLS 1.1 also removed certain ciphers such as DES, and RC2 which are vulnerable and broken and introduced support for Forward Secrecy, although it is performance intensive.

TLS 1.2, introduced in 2008, added SHA256 as a hash algorithm and replaced SHA-1, which is considered insecure. It also added support for Advanced Encryption Standard (AES) cipher suites, Elliptic Curve Cryptography (ECC), and Perfect Forward Secrecy (PFS) without a significant performance hit. TLS 1.2 also removed the ability to downgrade to SSL v2.0 (highly insecure and broken).

Why TLS 1.3?

TLS 1.3 is now an approved standard of the Internet Engineering Task Force (IETF).  Sites utilizing TLS 1.3 can expect faster user connections than with earlier TLS standards while making the connections more secure due to the elimination of obsolete and less secure ciphers, server dictating the session security and faster establishment of handshake between client and server. TLS 1.3 eliminates the negotiation on the encryption to use. Instead, in the initial connection the server provides an encryption key, the client provides a session key, and then the connection is made. However, if needed TLS 1.3 provides a secure means to fall back to TLS 1.2 if TLS 1.3 is not supported by the endpoint.

[You might also like: High-Performance Visibility into SSL/TLS Traffic]

TLS 1.3 – Recommendations

To achieve SSL/TLS acceleration and effectively address the growing number and complexity of encrypted web attacks, organizations face serious strategic challenges. We recommend migration to TLS 1.3 to take advantage of significant business benefits and security that the newer standard provides. However, as with any transition to a new standard, be mindful of the adoption risks.

Evaluate the Risks and Plan Migration

The risks may be incompatibility between client and server due to poor implementations and bugs. You may also need to carefully evaluate the impact on devices that implement inspection based on RSA static keys, products that protect against data leaks or implement out of path web application protection based on a copy of decrypted traffic.

  • Adopt a gradual deployment of TLS 1.3 – A crawl-walk-run approach of deploying in QA environments, test sites, and low traffic sites
  • Evaluate or query the “middle box” vendors for compatibility with TLS 1.3, currently, only active TLS 1.3 terminators can provide compatibility
  • Utilize Application Delivery Controllers (ADCs) to terminate TLS 1.3 and front-end servers that are not capable of supporting TLS 1.3

TLS 1.3 provides improved security, forward security to secure data even if private keys are compromised, improved latency and better performance.

Read “2017-2018 Global Application & Network Security Report” to learn more.

Download Now

Application Delivery

Considerations for Load Balancers When Migrating Applications to the Cloud

July 31, 2018 — by Prakash Sinha11

cloud-migration-load-balancing-960x600.jpg

According to a new forecast from the International Data Corporation (IDCWorldwide Quarterly Cloud IT Infrastructure Tracker, total spending on IT infrastructure for deployment in cloud environments is expected to total $46.5 billion in 2017 with year-over-year growth of 20.9%. Public cloud data centers will account for the majority of this spending, 65.3%, growing at the fastest annual rate of 26.2%. Off-premises private cloud environments will represent 13% of cloud IT infrastructure spending, growing at 12.7% year over year. On-premises private clouds will account for 62.6% of spending on private cloud IT infrastructure and will grow 11.5% year-over-year in 2017.

Application Delivery

Single Sign On (SSO) Use Cases

May 24, 2018 — by Prakash Sinha2

sso-use-cases-960x640.jpg

SSO reduces password fatigue for users having to remember a password for each application. With SSO, a user logs into one application and then is able to sign into other applications automatically, regardless of the domain the user is in in or the technology in use. SSO makes use of a federation services or login page that orchestrates the user credentials between multiple applications.

Application Delivery

Operational Visibility for Load Balanced Traffic in SDDC

March 13, 2018 — by Prakash Sinha0

load-balancing-sddc-1-960x720.jpg

Management and monitoring in Software Defined Data Centers (SDDC) benefit from automation principles, programmability, API and policy-driven provisioning of application environments through self-service templates. These best practices help application owners to define, manage and monitor their own environments, while benefiting from the performance, security, business continuity and monitoring infrastructure from the IT teams. SDDC also changes the way IT designs and thinks about infrastructure – the goal is to adapt to demands of continuous delivery needs of application owners in a “cloudy” world.

Application Delivery

Load Balancers and Elastic Licensing

February 22, 2018 — by Prakash Sinha1

load-balancing-gel-960x472.jpg

Last week I met with a very large enterprise in finance that has adopted provisioning on demand. They spin up applications on demand, having virtualized most of their infrastructure and have developed tools to automate the provisioning of applications and servers for customers and internal application developers through self-service applications.

Application Delivery

Load Balancers and Microservices

November 28, 2017 — by Prakash Sinha0

load-balancing-microservices-960x640.jpg

Many organizations, such as Netflix and Amazon, are using microservice architecture to implement business applications as a collection of loosely coupled services. Some of the reasons to move to this distributed, loosely coupled architecture is to enable hyperscale, and continuous delivery for complex applications, among other things. Teams in these organizations have adopted Agile and DevOps practices to deliver applications quickly and to deploy them with a lower failure rate than traditional approaches. However, you have to balance the complexity that comes with a distributed architecture with the application needs, scale requirements and time-to-market constraints.

Application Delivery

Securing Applications: Why ECC and PFS Matter

September 26, 2017 — by Prakash Sinha0

encryption-ecc-pfs-960x640.jpg

Many of us are familiar with Secure Hypertext Transfer Protocol (HTTPS) that uses a cryptographic protocol commonly referred to as Transport Layer Security (TLS) to secure our communication on the Internet. In simple terms, there are two keys, one available to everyone via a certificate, called a public key and the other available to the recipient of the communication, called a private key. When you want to send encrypted communication to someone, you use the receiver’s public key to secure that communication channel. Once secured, this communication can only be decrypted by the recipient who has the private key.