firewall - added “tls-host” firewall matcher
there is no documentation for this subject
http://forum.mikrotik.com/t/block-limit-youtube/114590/1
here is some info,
but this functions dont work for mee …
still there is no document on this now ability
i don’t know how to use this for filtering
This is decory 
Sent from my C6833 using Tapatalk
Doesn’t work for me either. Neither by full name, nor wildcard.
P.S. Also, why is this matcher added to NAT rules? There’s no info about TLS hostname in TCP SYN packets 
ME 3
TLS Host does not work in RouterOS 6.41.
Use last RouterOS 6.42rc15 (Release candidate).
work! https://t.me/cgood/208
There kind of is in recent TLS versions, supported by modern browsers and servers: SNI
I’m assuming this is what this matcher checks. However, browsers or other applications that don’t support this won’t send such packets, and thus would not be matched by this firewall matcher… So ideally you still want to deal with SNI-less packets somehow.
Important part is “in TCP SYN packets”, because it’s what is important for NAT, you can’t redirect connection later when SNI hostname comes.
SNI is a server thingy.
Opening a https webpage, always a certificate with name of website FQDN is requested. (this takes place after tcp 3 way handshake at session start)
In my understanding, this tls-host thingy is just a dedicated L7 filter, targeting this certificate name in SSL handshake
It is now added to the docs… And just as I said, it’s based on the SNI value. Although an interesting caveat is that the TLS handshake the client sends needs to be within a single packet for the matcher to work. And since TLS is on a higher OSI level than TCP, sure, the idea is similar to L7 filter, except that it only checks a specific format (TLS) in the first packet, making it technically a predefined L6 filter.
Still, how can we use TLS Host matcher in NAT rules if packets with SNI data are not processed by NAT rules? Looks like it’s some error
I’m guessing that this matcher doesn’t work on SYN and ACK packets, but instead it inspects the first content packets. The destination and source address are as determined without this matcher. And on a match, it terminates the original connection between router and server, and creates a new one to the new destination using the new source (as determined by rules including the matcher).
To the client, nothing would appear out of the ordinary, as long as the server at the final destination has the correct certificate. The final destination server would also not notice anything different. The original destination server would notice a TCP connection that gets immediately terminated, before the first packet from the client.
Well, simple testing shows that the matcher simply doesn’t work in NAT rules
I am not able to make it work on forwarded connections too,
Whut?..
It works for me in ****
/ip firewall filter chain=forward
rules in 6.41.1 as much as it can work. But bear in mind that you cannot combine it with
connection-state=new
for reasons stated above (the client-hello packet is sent after the TCP connection has already been established) so you can use the match to break the TCP session but not to e.g. redirect it to a dedicated WAN connection, it is too late to do that when that rule matches.
Sadly it doesn’t work with QUIC