Impact when moving from 2048 to 4096 bit RSA keys
Hi, I am trying to determine the impact of moving from 2048 bit RSA keys to 4096 bit RSA keys for a clientside ssl profile and would like to get some details of the impact when doing so. I read that the TPS would drop to 20% of what we would be capable when staying on 2048 bit keys. Assuming unlimited license. How much more latency would we have to face in the handshake process? Is there a list of incompatible clients available? Something like 'Outlook 2007, Firefox 12, ...' How much will the increased keysize strengthen the tls connection assuming we stick to the same cipher? Any other sideeffects? I did also open a F5 support case to this (C2910446 - Analysis of impact when moving from 2048 to 4096 bit RSA keys) but I was wondering if anyone from the community got some interesting ideas/comments to share. Once I get a proper response from F5 support I can share here as well as I think many might be interested. Cheers, TorstenSecuring SSL Keys on your BIG-IP
Losing your keys is a real problem While losing your car keys is indeed a pain, I mean losing your Web Server Keys. Lost keys can expose your website to a Man in The Middle (MiTM) Attack.While in the middle, an attacker can use those keys to decrypt the traffic between your clients and your servers. All of the data is open to be read by the hacker. How can we help make sure you're not the poor soul in the picture? Let's start with a little Crypto background. What is a Cryptographic key? A cryptographic key is pretty much like any other key.It unlocks a door; in this case, the door is a ciphered piece of text. I'll save the mechanics for what enciphering and deciphering are for another time, but suffice to say when traffic is encrypted, we need to encrypt it in such a way that it cannot be easily decrypted. In asymmetric encryption, there are two files – one is a certificate (the lock on the door—also known as the “public key”), and the other one is the key (the, uh, key?--also known as the “private key”). The certificate is the public part anybody can have.We share that readily, possibly through infrastructure that automatically transfers the info or delivers the certificate over a handshake or an email. An example of an RSA certificate file … slightly obfuscated because I am somewhat paranoid. The key itself is what stores the secret component, and it is the file we need to protect. An example of an RSA key file. Storing Cryptographic Files We can protect our key by storing it somewhere securely and ensuring that access is extremely limited. There are tools, like hardware security modules (HSM) that do this for us, and there are standards like Federal Information Processing Standard (FIPS) 140 (https://csrc.nist.gov/publications/detail/fips/140/3/final) which define many of the specifications around storing keys, including access and retention.When there are 1000s of keys to manage, it makes sense to invest in these tools. For others, we might just want to store them in a secure location, and there are several ways to do that. File Storage Indeed, the first is file access controls.We can limit access to these files using ACLs and read/write protection, and we definitely should do that.By default, on Linux distributions, you haveto correctly set the file permissions for some applications to even use your keys. Properly setting the file permissions is necessary, but with this mechanism alone, anyone who is able to get the necessary access to any of the systems storing the key can copy the key—it is just a small string of text--and do whatever they want with it. While gaining access to a BIGIP is not simple, there are many ways this can be done such as a disgruntled administrator, a vulnerability, a weak access password, and so on. Further, OpenSSL (www.openssl.org) provides a means to add a passphrase to this file so that instead of storing the file data as plain text, the file itself is enciphered with a passphrase even to read it. Shown here is a file – the same "key" even – without and then with a passphrase: Plaintext key file. You will notice that in the image above, we can read the key's text is displayed right after the header – that is THE KEY itself. Key file protected with an OpenSSL Passphrase enciphered with AES256. However, in the next image, there's a "Proc-Type:" and "DEK-Info:" header.The text of the file is NOT the actual key but an enciphered version of the key. Doing this means that, even with file access, an attacker would still need to get the Passphrase to use the key.It adds an extra factor of authentication to use the file.It is not as secure as a Hardware Security Module, but it is at least another layer of protection from unwanted access toyour keys. Now, note that the key itself has not changed.The file is the only change.Once you read the file with the proper access, the resulting key string remains the same. Passphrases and TMOS Within the BIG-IP configuration, these files are stored in an unencrypted version or an encrypted version depending on whether or not a Passphrase was supplied when they were loaded.To protect the Passphrase-protected files, TMOS includes Secure Vault (https://support.f5.com/csp/article/K73034260), which uses a "Master Key" which encrypts the file passphrases into the BIG-IP configuration.TMOS stores the OpenSSL Passphrase, but the Passphrase itself is stored in an encrypted format in the configuration files.To access the keys, you now need both the required TMOS access permissions and the Passphrase to read the contents. So, merely gaining access to the system is not enough to steal the key and use it to decrypt confidential data! Neat, huh? But Security is HARD!!! Yup, security is hard, and I would say moderately annoying, and a lot of people skip this step of adding the Passphrase to their keys. It is easier to store them as plain text, which allows loading them into TMOS without a Passphrase. When the keys are used in a Client or Server SSL profile, that pesky Passphrase isn't required. More comfortable, sure, but this isn't a smart or secure way to work. Plaintext keys came up recently with a customer.The customer had conducted a thorough security audit and determined that having keys available in plaintext on the file system was a possible threat to customer data integrity.This finding led to a requirement that all keys across the organization need to use a Passphrase. Great idea, but how could they retrofit the 100s of keys already loaded without a Passphrase? Luckily, OpenSSL provides a mechanism for managing the Passphrase associated with a key.You can change, add, or remove the Passphrase with a simple command. Here's the command if you want to copy it: openssl rsa -aes256 -in devcentral-example-key-open -out devcentral-key-protected Using this command, OpenSSL takes the "in" file and adds a Passphrase to the "out" file, enciphering it in the desired format specified (AES256). Fortunately, this is possible using the BIG-IP RESTful API and a few shell calls to manage the underlying files.The steps are: Copy the keys. Run the OpenSSL command to add a passphrase and encipher a copy of the file. Load the new, enciphered version of the key onto the BIG-IP. Get a list of the SSL Client and Server profiles using the plaintext key. Update these profiles with the new name of the encrypted key and Passphrase. Optionally remove the plaintext version of the key. I have built a sample script that does all this for you! I've posted it on my Github here https://github.com/pmscheffler/securekey, and you're welcome to take a copy and give it a try. Since it uses your keys, I would suggest thorough testing and making sure you're not using it in Production the first time out! Protecting the Keys to Your Door If you haven't adopted Passphrases on your keys because you thought it was too much effort to maintain, I hope you take a moment to check out the script and see that it isn't a lot to manage them in this manner. If you find the script useful or have another method you use – please let me know in the comments below. Hopefully, you never have a case where your customer data is exposed in a Man in the Middle breach because you lost your keys.
clientssl profile with ECC certificate needs RSA Certificate
Hello guys, Hope you could support me in the following matther. I have already purchased an ECC wildcard certificate and I wanted to attach it to a virtual server in my BIG IP 4200 LTM box which is running version 12.1.2. Everything went well until I got an error when creating a SSL client profile. It said "010717e3:3: Client SSL profile must have RSA certificate/key pair.", so I investigated and found that it is needed to have a RSA certificate/key in the profile besides the ECC pair. Therefore, I have the following questions about it: Do I need to generate two certificates (one ECC and other RSA) with the same FQDN on them? Is it possible? I am using Entrust to generate my certificates. How could I figure out which one certificate the BIG IP is showing to the client? How does the BIG IP select which certificate to show? Is there any possibility to make the BIG IP allows the creation of an SSL profile which uses an ECC certificate/key? In future releases perhaps? I have performed a couple of tests and it seems like the BIG IP is always showing the RSA certificate. Thanks in advance for your help. Best regards
RSA SECURID FIRST TIME LOGIN WITH APM
We have externals user without Access no other access to our internal resources that the one provided with APM. The authentication they use is RSA SecurID Token. They have been working so far with Juniper solution. But since we moved to F5 APM we have not been able to provide access to new users as the first time Login is not working. Should it work with F5 APM? The fist time login works this way: The first time an RSA OTP user logs in, they need to set a PIN for their token. This PIN is used in addition to the token code as the passcode. The user prepends the 8 character PIN to the token code. 1.Enter LOGIN: 2.Enter PASSCODE: (use token code only - 6 or 8 digit number) 3.Enter New PIN (Exactly 8 alpha-numeric characters, Must include 1 number and 1 letter) 4.Renter New PIN 5.Enter PASSCODE: (after token code has flipped enter PIN+TOKENCODE with no spaces) From this point on PASSCODE: refers to the PIN+TOKENCODE combination. Either 8+8 or 8+6 characters depending on software/hardware token type. If you are prompted for a Next Tokencode during login you will need to wait till your number rolls to the next one and enter it. 1.Enter PASSCODE: Wait for the tokencode to change, then enter the new tokencode : Each Tokencode can only be attempted to be used once and won't work a second time even if you mistype your PIN.
F5 Anti-Fraud Solutions: Frictionless Protection for the Masses
Anti-Fraud Solutions: Why F5? In 2013, F5 Networks grew its security portfolio to include advanced Anti-Fraud services with the acquisition of the Israeli-based security company Versafe. At the RSA Conference in San Francisco this week, we have a section of our F5 booth dedicated to the Anti-Fraud solution where we are talking about the technology, answering questions and demonstrating the capabilities all week. If you cannot make it to the conference or even if you attended but missed us at our booth, that’s not a problem. I’ll fill you in on some of the details. First, just walking around the RSA Conference, it’s clear that there is no shortage of anti-fraud solutions on the market. The number is mind blowing and continuously growing. As new threats emerge, new technologies are introduced to combat them. But if you look at the approaches each company takes, they are often quite different. So that begs the question: why F5? Well, from a feature and function standpoint, we cover a wide range of web-based fraud detection and protection capabilities. The WebSafe solution, which protects web-based applications, safeguards against various forms of malicious activity including phishing attacks, Man-In-The-Middle, Man-In-The-Browser and Trojan activity such as web injections, form hijacking, page modifications and transaction modification. But what makes the solution unique is that it enables 100% coverage of the user base in a completely clientless manner, without impacting the user experience. We inject our obfuscated code via an iRule, into the web application code as part of the response data. In other words, the solution is completely frictionless, which is key differentiator number one. And because the solution leverages common browser-based technologies, we protect users who are navigating from all types of devices: laptops, PCs, tablets, smart TVs, mobile devices, etc. As long as the user is navigating with a standard web browser, they will be protected. This is key differentiator number two. From a deployment standpoint, today the WebSafe solution is implemented via an iRule on an F5 device (either physical or virtual), so there is no need to introduce changes to the web applications our customers are looking to protect from online fraud. This saves time when deploying the solution because there is no need to engage web development resources which are often outsourced or already engaged in critical projects. Our ability to deploy without these web application changes equates to savings and is key value proposition number three. As a matter of fact, many F5 customers can leverage their current F5 investment and deploy the Anti-Fraud services on their existing infrastructure, requiring no additional hardware investment: differentiator number four. Lastly, WebSafe provides protection against online fraud without a client install and with no change in the online users’ experience. Introducing CAPTCHAs, popups, etc is often too intrusive to the end user, so we are looking to protect the users without introducing friction in the process. Summary If you are at the RSA Conference, stop by booth 1801. We would be happy to demonstrate our Anti-Fraud solution and help to enhance your fraud protection capabilities. If you are not at RSA, look for further details here. We will be posting more details about F5’s Anti-Fraud solutions throughout the coming weeks.
APM with for VMWare View with RSA auth.
So I'm trying to setup APM with VMWare View and RSA. I created SecureID View Client Logon and the user enters their email address and RSA key. Next I have the RS SecureID Auth configured but it looks like it's only passing the user name and not dot the full UPN, stripping off the domain name. RSA rejects the user since it does not have the full email address. ThankssecurID authentication via APM & username/pin/tokencode
Hi, when authenticating against an SecurID server there are 3 things needed: username pin-code token-code there is no documentation around which session variables have to be filled accordingly. there are only 2 session variables mentioned: session.logon.last.username and session.logon.last.password how do I have to fill this 3 pieces of information into those 2 variables ? remember: I do not want to authenticate against 2 different systems like AD AND RSA and send username/password to AD, and username/tokencode to RSA. I want to use RSA SecurID and nothing else. best regards, FlorianEncryption Basics: How RSA Works
The RSA Conference starts today in San Francisco, CA and we wanted to start off this week with a video that shows how RSA works. RSA is a public key cryptosystem that absolutely rocked the world of cryptography back in the 1970s. Maybe you've heard about RSA but you've never really understood how it works. Check out today's video to learn more about this amazing cryptosystem. Enjoy! Related Resources: Elliptic Curve Cryptography Ciphers Supported on BIG-IP
using the F5 for RSA Selfserviceconsole on port 7004
Hi out there I am (still) trying to get the RSA selfservice portal published via the F5 on a std SSL port. I have defined a default pool for the RSA server on port 7004 and I am publishing the external server on 443 I have put this irule on my VS running on port 443 and having the default pool for the intern server on port 7004: when HTTP_REQUEST { Disable the stream filter for requests STREAM::disable Remove this header to prevent server from compression response HTTP::header remove Accept-Encoding } when HTTP_RESPONSE { set internal_host "rsa.intern.local:7004" set external_host "rsaselfservice.extern.com" Rewrite the Location header for redirects if { [HTTP::header exists Location] }{ HTTP::header replace Location [string map "$internal_host $external_host" [HTTP::header Location]] } Rewrite the response content using a stream profile if it is text if { [HTTP::header Content-Type] contains "text" } { Set the stream expression with the find/replace strings STREAM::expression "@$internal_host@$external_host@" Enable the stream filter STREAM::enable } } but I get a 302 in return and it looks as if it loops a bit - can some tell me what is wrong with this little simple irule? Is it the response to the client which not gets correct re-written? br /ti
SecurID Authentication Failing on APM 12.1.2
I am having issues with SecurID authentication on a POC APM deployment. My first authentication attempt succeeds but any attempt after that fail with the following error. [root@AKOHDCPOCLTM01:Active:In Sync] config /usr/local/bin/securidtest -p "/config/aaa/ace/Common/rsaama01pakr.bfusa.com" -s 10...* -u username -w ********* ERROR: authentication with 'username' failed in doAuth:SD_Check(): authentication failed, code: 1, state: SECURID_AUTH_STATE_ACCESS_DENIED Test done: total tests: 1, success=0, failure=1 Some fields changed for privacy I can get a single authentication test to work by deleting the 'sdstatus.12' file. RSA is not able to tell me why that makes a difference. Any thoughts on this?
