rsa pub key authentication when AAA is enabled
Hello, we usually log in to our BIG IP with TACACs, working fine, now we'd like to have a special user, who should authenticate with rsa pub key. question: when I create a user, I can not define a password, I guess because of the AAA-Config, right? So I fear, this would only work, if we disable TACACS. If we configure the root-user with rsa pub key, there's still asking for Password. has anyone such a combination?
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
RSA Self Service iRule no longer works
I upgraded from 11.2 to 11.6 and the RSA secureID selfservice page that was working is no longer working. I have an irule that we are using Code when HTTP_REQUEST { if { [HTTP::header host] eq "PUBLIC.URL.COM" } { HTTP::header replace Host "ACTUAL_SERVER_FQDN:7004" } } when HTTP_RESPONSE { if { [HTTP::header Location] eq "ACTUAL_SERVER_FQDN:7004" } { HTTP::header replace Location [string map -nocase {ACTUAL_SERVER_FQDN:7004 PUBLIC.URL.COM} [HTTP::header value Location]] } } Everything was working great until we upgraded to 11.6. Now it looks like the http response part of the irule isn't working. Any updates to this irule to get it working in 11.6? Thanks!Securing 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.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, Torsten
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
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 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?Encryption 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
