Forum Discussion

Jibinpv's avatar
Jibinpv
Icon for Nimbostratus rankNimbostratus
Jan 16, 2017

Mutual Authentication

Hi Team,

 

Im having a scenario where a Mutual Authentication to be enabled for the customers connecting to the environment. Here We have only one virtual server having multiple customers connects to it and the traffic routing is bifurcated using the iRule taking the URI the requester connects to. For Eg- VS :- 10.1.1.1 (443) Domain VS maps to :- https://www.example.com Customer1 (myview):- https://www.example.com/myview Customer2 (ucom) :- https://www.example.com/ucom etc upto 80 diffrent customers.

 

So once the request comes in to VS,the iRule associated with it kicks it ,checks the URI to which the request is for and route the traffic to respective pool configured for the URI.

 

The SSL offloading is on the F5 for the domain.

 

Currently I have received request from only one customer and thus went ahead in enabling the Mutual authentication on the SSL profile which is currently associated with the VS.However it doesnt worked and was negative.

 

Also my worries is ,if more customers comes up with the Mutual Authentication - it will be a trouble to have that get done with only one VS.

 

Any best approached and thoughts please to get through it.

 

application delivery
LTM

3 Replies

Sort By
  • Hannes_Rapp's avatar
    Hannes_Rapp
    Icon for Nimbostratus rankNimbostratus
    Jan 16, 2017

    TLS handshake is lower in the stack - it takes place before you can check for the value of HTTP path your client has requested. This means with the use of One Virtual Server, you either apply mutual auth to everyone, or noone. Possible iRule workarounds may be possible with TLS invalidation and forced re-negotiation, but it gets pretty dirty and unmanageable.

     

    To help you move forward, I recommend you create 2 Virtual Servers

     

    • Opt 1. New Destination IP, new DNS name, mutual-auth enabled (Cleanest)
    • Opt 2. Alternatively, re-use the existing Destination IP and DNS name. For that, you must create a duplicate VS configuration with same destination IP and port, but with a different Source Address value. Closer-match VS will get the hit so two Virtual Servers with the same IP and Port combination can work. This solution is OK for one exception, but you would have to create a new Virtual Server for every new client (imo, not as clean or scalable as 1)
  • Kevin_K_51432's avatar
    Kevin_K_51432
    Historic F5 Account
    Jan 18, 2017

    Another option to consider, the TLS SNI feature was implemented for such a problem.

    Server Name Indication From Wikipedia, the free encyclopedia Server Name Indication (SNI) is an extension to the TLS computer networking protocol[1] by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. The desired hostname is not encrypted,[2] so an eavesdropper can see which site is being requested

    Implementing on the BIG-IP:

    K13452: Configuring a virtual server to serve multiple HTTPS sites using the TLS Server Name Indication feature

https://support.f5.com/csp/article/K13452

    Kevin