http redirect to https

HTTP and HTTPS connections on the same virtual server are not supported. As soon as you apply a clientssl profile to the virtual, any connection attempt will initiate the SSL handshake, and HTTP requests will be reset when the browser declines to negotiate the handshake.

 

 

You would need to create 2 different virtuals, changing either the port or the IP or both, then apply a variation of this simple rule (Click here ) to the HTTP virtual. (You'll need to modify the redirect line to include the appropriate port by inserting ":" just before [HTTP::uri], where is port of the HTTPS virtual.)

I don't disagree with you, just exploring potential here...could you do a tcp collect to look for the ssl headers, and if not present, issue an SSL::disable? I'm guessing no, but I thought I'd toss a bone to the deep thinkers out there...

after rereading my previous posting, its sounds like I'm excluding you from the deep thinker category , which isn't true. I really appreciate your thoughtful postings to the forum.

Headers and data alike are encrypted over an HTTPS connection, so the SSL handshake has to complete before any higher-level headers or data is exchanged.

 

 

If the client fails to send a CLIENT-HELLO (because it thinks it's communicating over HTTP), the handshake fails, and the connection is reset.

 

 

(It's the same chicken / egg scenario under which you can't dynamically pick a specific cert that matches the Host: header -- The header is not seen until after the handshake, which requires the cert...)

 

Citizen_elah, you are right. You could use TCP::collect to determine if the initial data packet looks like a plain text HTTP request or perhaps an SSL record and then use that logic to disable the SSL profile (with SSL::disable). As a matter of fact, I'm quite sure I posted an example of that some time ago... Maybe a search for SSL::disable will yield the result.

 

 

Sometimes I wish this forum software had more ways to search and categorize posts so finding old valuable stuff was a lot easier. Maybe someday that will happen... maybe not...

 

Hi Citizen --

 

 

No worries, I didn't take it that way. (Although some days, I must admit it's just as well I'm excluded... :~) )

 

 

I've learned alot from reading your posts as well. (Good call on the regex alternative earlier -- you beat me to it!)

 

 

/deb

Think outside the box... Basically, the idea is probably simpler than you are imagining. You configure an HTTPS virtual and then if the first data received is not encrypted, simply disable the SSL profile and don't decrypt the un-encrypted data, otherwise the data get's decrypted.

 

I found this post (Click here) that seems to be disabling SSL client-side with this code:

 

when CLIENT_ACCEPTED { 
  TCP::collect 5 
} 
when CLIENT_DATA { 
  if {[matchclass [TCP::payload] starts_with $::http_methods]}{
    SSL::disable 
  } 
}

 

 

Seems very simple, as you mention -- is this the approach you'd recommend?

 

No need to write a rule to do this. There is a profile option that allow SSL to enter passthrough mode for non SSL traffic.

 

 

bigpipe profile clientssl [profilename] nonssl enable

sheesh, nobody tells me nuthin'!

 

(I mean, I must have missed that in the release notes...)

 

 

I just searched AskF5, and the only hit I got was the list of reserved words.

 

 

In which version was the nonssl option added, bl0ndie?

 

 

thanks!

 

/deb