Search the Community

AWS Transfer Family now provides you with the option to import and use a trading partner’s public, self-signed TLS certificate for sending Applicability Statement 2 (AS2) messages to their server over HTTPS. Additionally, you can now choose to encrypt messages sent to your partner’s server using the 3DES cipher. By default, AS2 connectors will encrypt messages with the AES128 cipher unless you select 3DES for purposes of backwards compatibility with your partner’s existing AS2 implementation. These capabilities add to AWS Transfer Family’s existing list of AS2 interoperability features and enable you to reliably connect with trading partners that require these specific security configurations. View the full article

Have you ever encountered this frustrating error message when trying to make an HTTPS request from your .NET application? “System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.” If so, you are not alone. This error is quite common; it means that your client application cannot establish a secure connection with the server. In this article, I will show you how to diagnose and fix this error. What Does the Error Mean?The "Could not create SSL/TLS secure channel" error occurs when your application fails to establish a secure connection with the web server using the SSL/TLS protocol. SSL/TLS stands for Secure Sockets Layer/Transport Layer Security, a standard protocol for encrypting and authenticating data over the internet. When your application makes a web request, it initiates a "handshake" process with the webserver to negotiate the encryption and authentication parameters. This process involves exchanging certificates, keys, and cipher suites to ensure that both parties can communicate securely. If this process fails for any reason, the error is thrown. Check our article on Certified Kubernetes Administrator Exam Series (Part-6): Security, to get a better understanding of Kubernetes security. Why Does the Error Happen?There are many possible reasons why the error can happen, but they can be broadly categorized into client-side and server-side issues. Client-side issues: These are problems related to the configuration and settings of your application, such as the SSL/TLS protocol version, the security policy, the certificate validation, and the proxy settings. These issues can be fixed by changing the code or the configuration of your application. Server-side issues: These are problems related to the configuration and settings of the web server, such as the SSL/TLS protocol version, the certificate chain, the cipher suites, and the firewall rules. These issues can be fixed by changing the configuration or the code of the web server or by contacting the web service provider. Some of the common causes of the error are: The web server does not support the SSL/TLS protocol version that your application is using. The web server does not have a valid certificate, or the certificate is not trusted by your application. The web server does not support the cipher suites that your application is using.How to Fix the Error?Below are the different ways of troubleshooting and fixing the error. Scenario 1: The server does not support the SSL/TLS protocol version that your application is usingThis scenario can happen when the server is configured to use a higher or a lower protocol version than your application. For instance, the server may only support TLS 1.2 or higher while your application uses TLS 1.0 or lower. To diagnose this scenario, you can use Fiddler to see the protocol version your application and the server are using. To fix this scenario, you can either change the protocol version of your application or the web server so that they match or are compatible. To change the protocol version of your application, you can use the ServicePointManager.SecurityProtocol property. For example, to use TLS 1.2, you can add the following line of code before making the HTTPS request: ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls1.2; To change the protocol version of the server, you need to contact the server administrator or refer to the server documentation. Scenario 2: The server certificate is not trusted by your application or the systemThis scenario can happen when the server certificate is self-signed, expired, revoked, or issued by an untrusted authority. For example, the server may use a certificate that is generated by itself or by a private certificate authority that is not recognized by your application or the system. To troubleshoot this scenario, you can use Fiddler or Wireshark to see the server certificate and its trust chain. In Fiddler, you can see the server certificate by clicking on the padlock icon in the Sessions list and then clicking on the Certificates tab. In Wireshark, you can see the server certificate by expanding the ssl.handshake.certificate field of the ServerHello packet. To fix this scenario, you can either trust the server certificate or bypass the certificate validation. To trust the server certificate, add it to the list of trusted root certificates of your application or the system. In Windows, you can use the Certificate Manager tool (certmgr.msc) to import the certificate to the Trusted Root Certification Authorities store. Alternatively, you can use the X509Store class in .NET to programmatically add the certificate to the store. Below is a code sample that adds the certificate from a file. Using System.Security.Cryptography.X509Certificates; // Load the certificate from a file X509Certificate2 cert = new X509Certificate2("server.crt"); // Open the trusted root store X509Store store = new X509Store(StoreName.Root, StoreLocation.LocalMachine); store.Open(OpenFlags.ReadWrite); // Add the certificate to the store store.Add(cert); // Close the store store.Close(); To bypass the certificate validation, you can use the ServicePointManager.ServerCertificateValidationCallback property to specify a custom delegate that always returns true. Below is a code sample that ignores any SSL policy errors using System.Net; using System.Net.Security; using System.Security.Cryptography.X509Certificates; // Define a custom delegate that always returns true bool ValidateServerCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) { return true; } // Assign the delegate to the callback property ServicePointManager.ServerCertificateValidationCallback = ValidateServerCertificate;However, bypassing the certificate validation is not recommended, as it can expose your application to security risks like a man-in-the-middle attack. You should only use this option for testing purposes or when you trust the server completely. Check our course on Docker Certified Associate Exam Series (Part-6): Docker Engine Security, to learn how to secure your Docker hosts using TLS certificates. Scenario 3: The cipher suites supported by the server and your application do not matchThis scenario can happen when the server and your application have different preferences or requirements for the cipher suites that they use in the SSL/TLS session. For example, the server may only support strong cipher suites that use AES encryption and SHA-256 hashing, while your application may only support weak cipher suites that use RC4 encryption and MD5 hashing. Or the server may require a cipher suite that uses elliptic curve cryptography (ECC), while your application does not support ECC. Use Fiddler or Wireshark to see the cipher suites that your application and the server are offering and selecting. For example, in Fiddler, you can see the cipher suites in the Ciphers column of the Sessions list. In Wireshark, you can see the cipher suites in the ssl.handshake.ciphersuites field of the ClientHello and ServerHello packets. To fix this scenario, you can either change the cipher suites of your application or the server so that they have at least one common cipher suite. To change the cipher suites of your application, use the ServicePointManager.CipherSuites property. For example, to use only the cipher suites that use AES encryption and SHA-256 hashing, integrate the following code: using System.Net; using System.Net.Security; // Define a list of cipher suites that use AES and SHA-256 TlsCipherSuite[] cipherSuites = new TlsCipherSuite[] { TlsCipherSuite.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TlsCipherSuite.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TlsCipherSuite.TLS_RSA_WITH_AES_256_GCM_SHA384, TlsCipherSuite.TLS_RSA_WITH_AES_128_GCM_SHA256 }; // Assign the list to the property ServicePointManager.CipherSuites = cipherSuites;To change the server's cipher suites, you may need to contact the server administrator. How to test your HTTPS connection and verify that it is secure? After you have fixed the error and established a successful SSL/TLS connection with the server, you may want to test your connection and verify that it is secure. Below are some of the ways to do that: Use Fiddler or Wireshark to inspect the encrypted data that is exchanged between your application and the server. You can see the data in the Text View or Hex View tabs of Fiddler, or in the ssl.app_data field of Wireshark. You can also see the encryption algorithm and the key length that are used in the session in the Ciphers column of Fiddler, or in the ssl.cipher field of Wireshark.Use online tools such as SSL Labs or Qualys SSL Server Test to scan the server and check its SSL/TLS configuration and security. These tools can give you a detailed report on the server certificate, the protocol version, the cipher suites, and the vulnerabilities that the server may have. They can also give you a rating on the server’s SSL/TLS security, from A+ to F.Use the SslStream class to get information about the SSL/TLS session, such as the protocol version, the cipher suite, the key exchange algorithm, and the hash algorithm. You can access these properties from the SslStream object that is returned by the WebRequest.GetRequestStream or the HttpClientHandler.SslProtocols methods. Below is a sample code that gets the protocol version and the cipher suit.using System.Net; using System.Net.Security; // Create a web request to the server WebRequest request = WebRequest.Create("https://example.com"); // Get the request stream SslStream stream = (SslStream)request.GetRequestStream(); // Get the protocol version and the cipher suite string protocol = stream.SslProtocol.ToString(); string cipher = stream.CipherAlgorithm.ToString(); // Print the information Console.WriteLine("Protocol: {0}", protocol); Console.WriteLine("Cipher: {0}", cipher); Interested in learning more about Kubernetes security? Check out the following articles and courses from KodeKloud: 10 Kubernetes Security Best Practices to Secure K8 ClustersDevSecOps – Kubernetes DevOps & SecurityCertified Kubernetes Security (CKS): ConclusionIn this article, we have seen how to diagnose and fix the “Could not create SSL/TLS secure channel” error. I have also shown you how to test your HTTPS connection and verify that it is secure. I hope you have found this article helpful and interesting. If you have any questions or feedback, please feel free to leave a comment below. If you're keen on learning more about DevOps, simply sign up for a free account on KodeKloud. As a member, you'll gain access to over 70 courses, labs, quizzes, and projects designed to enhance your proficiency in various DevOps skills. View the full article

Kubernetes is an open-source tool that is utilized to execute and manage the containerized application inside the cluster. It performs various tasks to control, run, and secure the application’s credentials through secret and ingress. Ingress is used to manage application incoming traffic and also for SSL termination. In contrast, secrets are used to store confidential information and TLS certificates for application. This post will illustrate: What are the Kubernetes Secrets? Prerequisite: Generate Private Key and Certificate How to Create Secret TLS in Kubernetes? How to Create a Secret Through Yaml File? How to Embed Secret With Kubernetes Pod? Conclusion What are the Kubernetes Secrets? The Secrets are one of the Kubernetes resources, used to store confidential information such as user login credentials, keys, certificates, or tokens. The secrets can be created individually and connected to pods. It prevents the developer from providing confidential data in code and also provides an extra layer of security. Different kinds of secrets can be created and used. The most commonly used secrets are: Generic Secret: The generic secrets are utilized to store basic information such as passwords, tokens, API keys, OAuth keys, and so on. TLS Secret: TLS secrets are used to store private keys and certificates that are signed by the CA. To ensure the security of applications running inside Kubernetes and for securing communication within the cluster, the user usually needs to create and embed TLS secrets to the pod. Docker Registry: It is used to store the docker registry credential to easily pull the images from the registry. Prerequisite: Generate Private Key and Certificate To create the certificate and private key for security improvement, utilize OpenSSL that creates the CSR (certificate signing request) and private key. Then, use CSR to generate the self-signed or CA certificates. To utilize the OpenSSL commands on Windows, users are required to install Git. For this purpose, follow our linked “Install git on Windows” article. After installing git, follow the below instructions to generate a private key and signed certificate. Step 1: Launch Git Bash Terminal Make a search for “Git Bash” in the Start menu and launch the terminal: To check the current directory use the “pwd” command: pwd Currently, we are working in the %USERPROFILE% directory: Step 2: Create New Directory Create a new directory to save the certificates and private key: mkdir cert Navigate to the newly created directory using the “cd” command: cd cert Step 3: Generate Private Key Now, generate the private key through the given command. Here, the generated private key will be saved in “mycert.key”: openssl genpkey -algorithm RSA -out mycert.key Step 4: Generate CSR To generate the CSR (certificate service request) to get a signed certificate, use the given command: openssl req -new -key mycert.key -out mycert.csr Step 5: Generate Certificate Lastly, using the generated private key and CSR, create a certificate and save it in the “mycert.crt” file. For this purpose, execute the below command: openssl x509 -req -in mycert.csr -signkey mycert.key -out mycert.crt -days 365 After generating the TLS certificates, the user can create the secret TLS by following the below section. How to Create Secret TLS in Kubernetes? To ensure the application security and secure communication within and outside the Kubernetes cluster, the TLS (Transport Layer Security) certificates are essential that are used in data encrypting. The Kubernetes secret allows us to embed the TLS certificate with running pods through secret TLS. To create a secret TLS in Kubernetes, go through the following instructions. Step 1: Start Minikube Cluster To start the minikube cluster, first, launch the Windows PowerShell as administrator. After that, create and run the cluster using the “minikube start” command: minikube start Step 2: Get Nodes Access the Kubernetes node to check if the cluster is started or not: minikube get nodes Step 3: Create Secret TLS Create the TLS secret in Kubernetes using “kubectl create secret <secret-type> <secret-name> –cert=<path-to-tls certificate> –key=<path-to-private-key>” command. Here, the secret type can be “generic”, “tls”, or “docker-registry”. To create a TLS secret, we have set the secret type as “tls”: kubectl create secret tls demo-secret --cert=C:\Users\Dell\cert\mycert.crt --key=C:\Users\Dell\cert\mycert.key Step 4: Get Secrets For confirmation, list down the Kubernetes secret using the given command: kubectl get secret Here, you can see we have effectively created a “demo-secret” that contains “2” data values: Step 5: Describe Secret To view how data are viewed or stored in secret, describe the secret using the “kubectl describe secret <secret-name>” command: kubectl describe secret demo-secret You can see values are stored in bytes and cannot be directly viewed unlike Kubernetes ConfigMaps: How to Create a Secret TLS Through Yaml File? To create a secret TLS through a yaml file, first, create a “secret.yml” file, add the tls base64 encoded certificate in the “tls.crt” key, and add the base64 encoded key in the “tls.key”. For demonstration, follow the listed steps. Step 1: Create Yaml File Create a file named “secret.yml” and paste the given code: apiVersion: v1 data: tls.crt: "base64 encoded cert" tls.key: "base64 encoded key" kind: Secret metadata: name: mytls-secret namespace: default type: kubernetes.io/tls In the above snippet, replace the “tls.crt” and “tls.key” key values with your original certificate and key values: Step 2: Create a Secret Now, apply the secret yaml file through the “kubectl apply -f <path-to-secret.yml>” command: kubectl apply -f secret.yml The output shows that we have successfully created the “mytls-secret” using yaml file: Note: View TLS Certificate and Private Key To view the base64 encoded certificate and use it in the yaml file, run the “cat <path-to-certificate file> | base64” command in the git bash terminal: cat mycert.crt | base64 In order to view the base64 encoded key, use “cat <path-to-key file> | base64” command: cat mycert.key | base64 How to Embed Secret TLS With Kubernetes Pod? After creating the secret TSL, the user can embed it with the Kubernetes pod. To do so, use the following instructions. Step 1: Create Yaml File Make a file named “pod.yml” file and paste the below snippet into the file: apiVersion: v1 kind: Pod metadata: name: demo-pod spec: containers: - name: html-cont image: rafia098/html-img:1.0 envFrom: - secretRef: name: demo-secret In the above snippet: “kind” key specifies the Kubernetes resource that the user is creating. “name” key will set the pod name. “containers” key will store the container information. “name” key under the “containers” key will set the container name. “image” key will provide the application or container image to create and start the application inside the container. “envFrom” key will set the environment variable from other Kubernetes resources. Here, to embed the secret TLS in a pod, “secretRef” is used to provide a secret reference. To embed the above secret TLS, specify the name of the secret in the “name” key. Step 2: Create or Upgrade the Pod Next, open the folder where the “pod.yml” file is created: cd C:\Users\Dell\Documents\Kubernetes\Secret Apply the yaml file to create or reconfigure the pod using the “kubectl apply” command: kubectl apply -f pod.yml Step 3: Access Kubernetes Pods For verification, list down the Kubernetes pods: kubectl get pod Here, you can see we have created the “demo-pod” successfully: Step 4: Describe the Pod To check if the pod has embedded the secret TLS or not, describe the pod using the below command: kubectl describe pod demo-pod The below output shows that we have successfully embedded the TLS secret with pod: We have covered how to create secret TLS and embed it with the Kubernetes application running in the pod. Conclusion To create the secret TLS in Kubernetes, first, create the TLS signed certificate and private key. After that, start the Kubernetes cluster and run the “kubectl create secret <secret-type> <secret-name> –cert=<path-to-tls certificate> –key=<path-to-private-key>” command. Users can also create the secret TLS using yaml manifest. This post has illustrated how to create the secret TLS and how to embed the secret with a running application or pod. View the full article

Don’t be surprised if you have seen the Certificate Update in the Amazon Relational Database Service (Amazon RDS) console. If you use or plan to use Secure Sockets Layer (SSL) or Transport Layer Security (TLS) with certificate verification to connect to your database instances of Amazon RDS for MySQL, MariaDB, SQL Server, Oracle, PostgreSQL, and Amazon Aurora, it means you should rotate new certificate authority (CA) certificates in both your DB instances and application before the root certificate expires. Most SSL/TLS certificates (rds-ca-2019) for your DB instances will expire in 2024 after the certificate update in 2020. In December 2022, we released new CA certificates that are valid for 40 years (rds-ca-rsa2048-g1) and 100 years (rds-ca-rsa4096-g1 and rds-ca-ecc384-g1). So, if you rotate your CA certificates, you don’t need to do It again for a long time... View the full article

The introduction of 5G networking and its accompanying Service-Based Architecture (SBA) control plane brings a noteworthy shift: Instead of a traditional design consisting of proprietary signaling between physical, black-box components, SBA uses a commodity-like, microservice implementation that is increasingly cloud native, relying on standard RESTful APIs to communicate. This requires a reset in how carriers implement security, one where proven cloud concepts will likely play a significant role. This post will show how the HashiCorp suite of products, especially HashiCorp Vault’s PKI functionality, are well suited for SBAs and cater to a variety of 5G core use cases, with tight Kubernetes integrations and a focus on zero trust networking. These tools provide a strong foundation for 5G environments because many of the constructs included in SBA resemble a modern, zero trust service mesh. Vault in particular offers full PKI management and a low-resistance path for service providers seeking to minimize the software development effort required to achieve mTLS compliance. »The New Face of Telecom Networking The 3GPP standards body mandates a 5G mobile packet core based on discrete software components known as Network Functions (NF). The specifications clearly articulate requirements for NF communication pathways (known as reference points), protocols, service-based interfaces (SBI), and critically, how these network channels are secured. SBI representation of a 5G service-based architecture Orchestration platforms have opened up powerful integration, scaling, and locality opportunities for hosting and managing these NFs that were not possible in earlier manifestations of cellular technology. A mature 5G core could span multiple datacenters and public cloud regions, and scale to thousands of worker nodes. An entire Kubernetes cluster, for example, may be dedicated to the requirements of a single NF: internally, a function may consist of many pods, deployments, services, and other Kubernetes constructs. The SBI itself could be any network interface associated with an NF that is attached to the control plane network for the purpose of consuming and/or providing a service in accordance with the specification. The 5G SBA also brings new security challenges and opportunities. »Securing Network Function Communication Security architecture and procedures for 5G System (3GPP TS 33.501) is the document of record that details various security-related requirements within 5G SBA. Section 13.1.0 states: All network functions shall support mutually authenticated TLS and HTTPS as specified in RFC 7540 [47] and RFC 2818 [90]. The identities in the end entity certificates shall be used for authentication and policy checks. Network functions shall support both server-side and client-side certificates. TLS client and server certificates shall be compliant with the SBA certificate profile specified in clause 6.1.3c of TS 33.310 [5]. mTLS is a fundamental requirement within the 5G SBA for securing SBI flows at the authentication level. But what about authorization? One NF in particular is especially crucial in the context of security: the Network Repository Function (NRF) is responsible for dynamically registering all SBA components as they come online, acting as a kind of service discovery mechanism that can be queried in order to locate healthy services. In addition, the NRF has universal awareness of which functions should be permitted to freely communicate, issuing appropriately scoped OAuth2 tokens to each entity. These tokens authorize network flows between NFs, further securing the fabric. NF authentication and authorization flow There are two modes of service-to-service communication described in the 3GPP specifications. In the Direct Communication mode, NFs engage in service discovery and inter-function network operations as explained above. However, in the Indirect Communication mode, a Service Control Proxy (SCP) may optionally intercept flows and even broker discovery requests with the NRF on behalf of a consumer. Various SCP implementations can augment SBA service networking by introducing intelligent load balancing and failover, policy-based controls, and monitoring. »If it Looks Like a Mesh, Walks Like a Mesh… To summarize, the 5G SBA includes a number of broad technology constructs: Microservice architecture based on Kubernetes Hybrid-cloud/multi-cloud capabilities Service discovery and load balancing Network authentication via mTLS OAuth2 token-based authorization Optional proxy-based mode (policy and telemetry) If this is starting to sound familiar, you’re not alone. While the indirect communication mode is optional (and does not specify a sidecar proxy), these elements combined closely resemble a modern, zero trust service mesh. Intentional or not, this emergent pattern could evolve towards the same architectural trends, platforms, and abstractions being adopted elsewhere in modern software. To that end, HashiCorp‘s enterprise products cater to a variety of core 5G use cases, with tight Kubernetes integrations and a keen focus on zero trust networking: HashiCorp Terraform: Builds reliable multi-cloud infrastructure and deploys complex workloads to Kubernetes using industry-standard infrastructure as code practices HashiCorp Consul: Discovers services and secure networks through identity-based authorization HashiCorp Vault: Protects sensitive data and delivers automated PKI at scale to achieve mTLS for authenticated SBI communications HashiCorp Vault in particular presents an attractive solution for easily securing SBI flows with mTLS authentication. Vault is a distributed, highly available secrets management platform that can span multiple private and public cloud regions, accommodating a wide variety of SBA consumer personas and environments. Several replication options offer robust disaster recovery features, as well as increased performance through horizontal scaling. Vault high-availability architecture »Certificate Lifecycle Automation with Vault The PKI functionality of Vault (one of many secret engines available) is powerful, comprehensive, and simple to implement. Vault supports an arbitrary number of Certificate Authorities (CAs) and Intermediates, which can be generated internally or imported from external sources such as hardware security modules (HSMs). Fully automated cross-signing capabilities create additional options for managing 5G provider trust boundaries and network topologies. Access to Vault itself must be authenticated. Thankfully, this is a Kubernetes-friendly operation that permits straightforward integration options for container-based NF workloads. Supported authentication methods include all of the major public cloud machine-identity systems, a per-cluster native Kubernetes option, and JWT-based authentication that incorporates seamlessly with the OIDC provider built into Kubernetes. The JWT-based method is capable of scaling to support many clusters in parallel, utilizing the service account tokens that are projected to pods by default. Once successfully authenticated to Vault, a policy attached to the auth method dictates the client’s ability to access secrets within an engine. These policies can be highly granular based on a number of parameters, such as the client’s JWT token claims, Microsoft Azure Managed Identity, AWS Identity and Access Management (IAM) role, and more. Vault logical flow from authentication to secret consumption If a policy grants access to a PKI secrets engine, the client may request a certificate specifying certain parameters in the API request payload, such as: Common name Subject alternative names (SANs) IP SANs Expiry time The allowed parameters of the request are constrained by a role object configured against the PKI engine, which outlines permitted domain names, maximum TTL, and additional enforcements for the associated certificate authority. An authenticated, authorized, and valid request results in the issuance of a certificate and private key, delivered back to the client in the form of a JSON payload, which can then be parsed and rendered to the pod filesystem as specified by the NF application’s requirements and configuration. The processes described to authenticate and request certificates can be executed by API call from the primary container, aninitcontainer, or any of a number of custom solutions. To reduce the burden of developing unique strategies for each NF, organizations may instead choose to leverage the Vault Agent Injector for Kubernetes to automate the distribution of certificates. This solution consists of a mutating admission controller that intercepts lifecycle events and modifies the pod spec to include a Vault Agent sidecar container. Once configured, standard pod annotations can be used by operations teams to manage the PKI lifecycle, ensuring that certificates and private keys are rendered to appropriate filesystem locations, and are renewed prior to expiry, without ever touching the NF application code. The agent is additionally capable of executing arbitrary commands or API calls upon certificate renewal, which can be configured to include reloading a service or restarting a pod. The injector provides a low-resistance path for service providers seeking to minimize the software development effort required to achieve mTLS compliance. Vault JWT Auth Method with Kubernetes as OIDC provider Vault also integrates with Jetstack cert-manager, which grants the ability to configure Vault as a ClusterIssuer in Kubernetes and subsequently deliver certificates to Ingresses and other cluster objects. This approach can be useful if the SBI in question specifies a TLS-terminating Ingress Controller. Software vendors building 5G NFs may alternatively decide to incorporate Vault into their existing middleware or configuration automation via a more centralized API integration. For example, a service may already be in place to distribute certificates to pods within the NF ecosystem that have interfaces on the SBI message bus. This solution might rely on a legacy certificate procurement protocol such as CMPv2. Replacing this mechanism with simple HTTP API calls to Vault would not only be a relatively trivial effort, it would be a shift very much in the spirit of the 3GPP inclination towards standard RESTful, HTTP-based communications, and broader industry trends. »Working Together to Make 5G More Secure HashiCorp accelerates cloud transformation for Telcos pursuing automation, operational maturity, and compliance for 5G networks. Join the HashiCorp Telco user group to stay up to date with recent developments, blog posts, talk tracks, and industry trends. Reach out to the HashiCorp Telco team at telco@hashicorp.com. View the full article

Great post about application authentication and authorization on AWS; https://blog.cloudcraft.co/application-authentication-and-authorization-on-aws/

Amazon CloudFront now supports Transport Layer Security (TLS) 1.3 session resumption to further improve viewer connection performance. Until now, Amazon CloudFront has supported version 1.3 of the TLS protocol since 2020 to encrypt HTTPS communications between viewers and CloudFront. Customers that adopted the protocol have seen their connection performance improved by up to 30% compared with previous TLS versions. Starting today, customers that use TLS 1.3 will see up to 50% additional performance improvement thanks to TLS 1.3 session resumption. With session resumption, when a client reconnects to a server with which the client had an earlier TLS connection, the server decrypts the session ticket using a pre-shared key sent by the client and resumes the session. TLS 1.3 session resumption speeds up session establishment as it reduces computational overhead for both the server and the client. It also requires fewer packets to be transferred compared to a full TLS handshake. View the full article

CloudFront now provides the CloudFront-Viewer-TLS header for use with origin request policies. CloudFront-Viewer-TLS is an HTTP header that includes the TLS version and cipher suite used to negotiate the viewer TLS connection. Previously, TLS information was available in CloudFront access logs to analyze previous requests. Now, customers can access the TLS version and cipher suite in each HTTP request to make real-time decisions such as restricting requests with outdated TLS versions. The CloudFront-Viewer-TLS header value uses the following syntax: <TLS version>:<Cipher Suite>. For example, TLSv1.2:ECDHE-RSA-AES128-SHA256. View the full article

Microsoft is making changes to their certificates and it is important to understand how these changes will impact your deployments. Azure will be changed to use TLS certificates from a different set of Root Certificate Authorities (CAs). This change is being made because the current CA certificates do not comply with one of the CA/Browser […] The article Azure TLS certificate changes appeared first on Build5Nines. View the full article

Amazon Neptune now enforces a minimum version of TLS v1.2 and Secure Sockets Layer (SSL) client connections to Neptune in all AWS Regions where Neptune is available with the latest engine release, 1.0.4.0. View the full article

ACM for Nitro Enclaves is an enclave application that allows you to use public and private SSL/TLS certificates with your web applications and servers running on Amazon EC2 instances with AWS Nitro Enclaves. SSL/TLS certificates are used to secure network communications and establish the identity of websites over the Internet as well as resources on private networks. Nitro Enclaves is an EC2 capability that enables creation of isolated compute environments to protect and securely process highly sensitive data, such as SSL/TLS private keys. View the full article