Firewall decisions based on SNI field?

[Vladimir_Ostrovsky]

Hi all,

Does anybody know if FortiGate can be configured to do this?

[ul]

When a client opens a TCP connection to predefined port (typically, HTTPS), respond to the TCP handshake on behalf of a server.

Accept the "Client Hello" TLS message from the client,

Read the server's hostname specified in the SNI field of the "Client Hello".

Check the hostname against "destination" of the firewall policies - maybe by performing its own DNS resolution to see if the IP falls into allowed ranges, or maybe by textual comparison if the destination is set as some regexp object?

Make a Allow/Block decision based on the result?[/ul]

Today, when virtually any TLS client supports the SNI field, this would be very useful feature.

Thanks,

Vladimir.

[Vladimir_Ostrovsky]

This should be essentially the same as the use of "[link=https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CONNECT]CONNECT hostname:443 HTTP/1.1[/link]" header by Explicit Proxy for HTTPS connections. The Proxy also responds to TCP handshake, then reads this header and makes decisions based on this hostname.

I'm just looking for a way to implement the same thing without using the Explicit Proxy.

[emnoc]

A LB will do this with ease and is how multiple websites are hosted on a SLB with numerous pool members. Have you looked at the fortiweb product line? I'm sure it has that ability and probably GEOIP support for the sources. We use to do that with in F5-LTM and iRules to restrict certain websites based on src-address or geo information.

Since the  fortigate has a basic SLB, I would explore the  fortiweb features.

Ken Felix

[Vladimir_Ostrovsky]

Probably my question wasn't clear enough - it's about filtering outgoing HTTPS traffic, so LB is not really applicable here.

I just found this CheckPoint paper, "URL Filtering using SNI for HTTPS websites" - it demonstrates how to achieve this, but I'd glad to do it with FortiGate.

[boneyard · Accepted solution]

FortiGate should look at the SNI by default for webfiltering according to this article:

https://kb.fortinet.com/k....do?externalID=FD34661

your feature to use it in the ipv4 policy is sort of using a webfilter profile with fixed entries in my opinion. but to have it happen automatically is not something how the fortigate operates on layer 4.

the question to keep in mind is how long this be useful, SNI is close to getting encrypted, once that happens the feature becomes useless.

[Vladimir_Ostrovsky]

Yes, thanks for the link to the KB, but it raises more questions than it replies to.

[ul]

As I understand, it says that SNI hostname is checked to see if it's "valid". It's not clear what "valid" means - resolvable by DNS?

Is it compared against hostname in  CN or SAN fields of the received certificate?

Is it checked against destination IP address that the connection was initiated to, or against "destination" field in the matched firewall policy?[/ul]

Is there any documentation that goes in depth on the order in which FortiGate processes all this?

Thanks,

Vladimir.

[emnoc]

[ul]

As I understand, it says that SNI hostname is checked to see if it's "valid". It's not clear what "valid" means - resolvable by DNS?[ul]

probably for SNI too work it needs proper DNS, so yes  a DNS RR a-type must exists. This is the basic for certificate and SNI.[/ul]

Is it compared against hostname in  CN or SAN fields of the received certificate?[ul]

As stated before;  " the  CN field in a altName certificate is a mute point"  it's not use or check or has any bearing on proper x.509 certificates[/ul]

Is it checked against destination IP address that the connection was initiated to, or against "destination" field in the matched firewall policy?

[ul]

If your using  webfiltering than the destination address is not relevant. How fortiguard  lookup works it is looks at the host header ( http ) or SNI ( https ) and compare that to the URL category . If it matches  and permitted, the traffic is applied. If your category says block, the traffic is blocked.[/ul][/ul]

The question I guess are you  doing cert or ful-cert inspection in your FGT appliance?  the later would be full-decrypt and re-encrypted with your CA cert.

I believe on testing the , the certificate validation and trust worthly of the web-server is never fully intercepted. I.e how much verification is done against CRL/OCSP is very questionable if any is even being done. You can use badssl to verify a lot of this.

http://socpuppet.blogspot.com/2016/12/how-to-test-various-bad-ssl.html

( the last line of that post )

I would enable full-ssl-inspection and  test the various test scenario with the fortigate and it would be clear on what it does or does not doing with regards to TLS decryption. Also you will find the  earlier fortios and later version works the approx the same and with the same outcome.

Remember the SSL inspection is not a full blown proxy but does provide great prevention for webtraffic

Ken Felix

[Vladimir_Ostrovsky]

Thank you, Ken,

So do I understand this right?

Let's say, my FortiGate doesn't limit outgoing HTTPS traffic by destination IP (connections to 0.0.0.0/0 are allowed) - but it does limit it by some Static URL Filter, allowing traffic only to some whitelist of sites. Let's say, one of them is [link=https://mail.google.com]mail.google.com[/link].

If a user on my network wishes to establish connection to some [link=https://badsite.com]badsite.com[/link], which resolves to 11.22.33.44, and if this site presents a certificate for [link=https://mail.google.com]mail.google.com[/link] (self-signed or signed by some its own CA) - then all that this user has to do is to add a record into his hosts file: 11.22.33.44 mail.google.com

FortiGate will find the matching firewall rule for destination 11.22.33.44 (which is covered by 0.0.0.0/0), then inspect SNI value (which is mail.google.com) and CN (which is also mail.google.com) and happily allow the connection. It's not possible to make it check whether mail.google.com indeed resolves to 11.22.33.44 or whether the received certificate is issued by some well-known CA (or specifically by GlobalSign, which issued certificate for real [link=https://mail.google.com]mail.google.com[/link]).

So the only way to prevent this is to use Explicit Proxy - in this case, FortiGate will perform DNS lookup by itself and select the destination IP by itself (although CA won't be checked in this case as well).

Is this correct?

Thanks, Vladimir.

[romanr]

Vladimir.Ostrovsky wrote:

Thank you, Ken,

...

So the only way to prevent this is to use Explicit Proxy - in this case, FortiGate will perform DNS lookup by itself and select the destination IP by itself (although CA won't be checked in this case as well).

Hey,

using explicit proxy will be the only way to fully achieve what you want.

If you're staying in a transparent setup you could consider using the "Rate URLs by domain and IP Address" feature of the webfilter which would at least block access to sites if the IP based rating would tell something different to the requested host header information.

Also you will need to think about ssl-interception if your requirements should work with TLS 1.3 as well - the host header is encrypted there! Acting only passively on layer 4 will make a firewall blind!

Br,

Roman

PS: Edit Typos

[emnoc]

Agreed

And in your example that you give with mail.google.com is exactly how we test F5 Virtual-Servers before we put them in production by change the test machine DNS record to match the site that we will migrated. Since SNI or even http_host header ( HTTP ) would match the url filter, the site is really not the real site but the traffic would be accepted and passed by the NGFW.

You need a full-blown proxy if you want to check DNS and matching AltName or CN in a certificate. And even tho, someone could  hack DNS mail.google.com ( just as an example ) and forge DNS replies to a rouge hacker mail.google.com, your proxy would probably not prevent the webbrowser connection unless they look at the CAA dns resource record  or had specific certificate-details cached to know the imposter site is NOT mail.google.com ( i.e cert issuer, exp-data,serial# or fingeprint,etc.......). This was why cert-pinning was developed.

BTW: On the CN  ( common name ) almost nobody cares of what the CN value is present  AND if the Subject if an AlternateName field is present. Almost every web-browser down to mobile devices looks at altName if present and ignores the CN. My understanding on PKI and certificates, the CN never intended to be use for the site hostname , but just some how it was used for this. Almost all sites nowadays seem to use a altName field. Even if it's not a real multiple altName SAN.

i.e ( all of the these are multiple AltNames )

bankofamerica

ebay

paypal

googles various sites

cnn

Even a single site that has a certificate issued is typically still using a altName field

i.e

www.yourdomainsite.com

 Alternative Name:                 DNS:www.yourdomainsite.comsubject:                /C=US/ST=Texas/L=Austin/O=mycompany/OU=webshost/CN="businesss unit 1234567 "  I wrote a blog post showing what happens & with a few browsers and how the CN fields is igonre, when using altName. http://socpuppet.blogspot.com/2017/11/cn-and-subject-alternative-names-in.html So don't worry about CN when the certificate has the altName field. The RFC was revised to include this also explain the altname  RFC5280. On a side note, I signed a CSR where the CN was not even presented in a SANS certificate request. Most CA will not do this btw, they always check for a CN value,  but the value could be anything. This also leads to false positive on vulnerability testers. Especially when they find CN values that are not resolvable in DNS and with a Subject AltName is present. i.e    CN="*.example.com"   altName=www.example.com,example.com Looks good , right ? But that's not resolvable. Just food for thought. Just ignore the CN value &  if Subject AltName is being used ;) Ken Felix