# Bingbot SNI handling (terminate at TLS layer)
**URL:** https://discourse.haproxy.org/t/bingbot-sni-handling-terminate-at-tls-layer/249
**Category:** Help!
**Created:** [May 2, 2016, 9:43pm UTC](https://discourse.haproxy.org/t/bingbot-sni-handling-terminate-at-tls-layer/249 "2016-05-02T21:43:17Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@jgelens](https://discourse.haproxy.org/u/jgelens)
#### Post date: [May 2, 2016, 9:43pm UTC](https://discourse.haproxy.org/t/bingbot-sni-handling-terminate-at-tls-layer/249/1 "2016-05-02T21:43:17Z")
My server solely serves SSL SNI domains and therefore no default fallback for non sni clients configured. Clients which do not support SNI will get a 503 because of that reason.
However, I’m having some problems with bingbot to work with SNI and after talking with their product team they replied the following:
> Basically, how it works is that our bots first offer a TLS handshake to the server withoutSNI info. If the web server refuses this at the TLS layer, Bingbot will know to then offer a TLS handshake withSNI info. Returning a 503 will prevent Bingbot from detecting that it needs to send SNI info. Also, if the handshake is terminated at a deeper layer than the TLS layer, Bingbot will also not take proper action on this.
> As I understand it in simpler terms, Bingbot comes to a secret club and asks to come in without saying the password. Because Bingbot didn’t say the password, the bouncer lets Bingbot in but shows him an empty room and then kicks him out the backdoor. Bingbot leaves confused and upset. If the bouncer had refused entry, Bingbot would have remembered to say the password and the bouncer would have lead him to the party.
> The Product Team can’t offer anything else besides this explanation on properly terminating the HTTPS handshake so that our bots can make the correct handshake request.
> Please configure the server so that HTTPS handshake is terminated if the client “hello” doesn’t contain the expected SNI server name. Basically, if there is an error on TLS layer, the TLS handshake should terminate. Returning info through the higher HTTP layer is too late.
> If the web server refuses the TLS handshake when the TLS request doesn’t contain SNI info, Bingbot will be able to determine that SNI might be required and do a retry.
So my question is: how can I configure haproxy to refuse at the TLS layer?
My config is as follows:
> frontend www-ssl
> mode http
> bind 0.0.0.0:443 ssl crt /usr/local/etc/haproxy/certs
> use\_backend %[ssl\_fc\_sni,lower,map\_end(/usr/local/etc/haproxy2/ssl\_domains.map)]
Thanks!
---
### Author:  [@lukastribus](https://discourse.haproxy.org/u/lukastribus)
#### Post date: [May 2, 2016, 10:00pm UTC](https://discourse.haproxy.org/t/bingbot-sni-handling-terminate-at-tls-layer/249/2 "2016-05-02T22:00:55Z")
Easy, just configure [strict-sni](http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.1-strict-sni) on your bind line.
---
### Author:  [@jgelens](https://discourse.haproxy.org/u/jgelens)
#### Post date: [May 2, 2016, 10:02pm UTC](https://discourse.haproxy.org/t/bingbot-sni-handling-terminate-at-tls-layer/249/3 "2016-05-02T22:02:23Z")
Yep tried that, but bingbot says in that case :
> ```
> One or more fetch attempts were performed but they failed.
>
> ```
☹
---
### Author:  [@lukastribus](https://discourse.haproxy.org/u/lukastribus)
#### Post date: [May 2, 2016, 10:03pm UTC](https://discourse.haproxy.org/t/bingbot-sni-handling-terminate-at-tls-layer/249/4 "2016-05-02T22:03:30Z")
Then talk about that with their support. strict-sni is doing exactly what they are asking above.
---
### Author:  [@jgelens](https://discourse.haproxy.org/u/jgelens)
#### Post date: [May 2, 2016, 10:05pm UTC](https://discourse.haproxy.org/t/bingbot-sni-handling-terminate-at-tls-layer/249/5 "2016-05-02T22:05:34Z")
Thanks, will do and let you know.
---
### Author:  [@lukastribus](https://discourse.haproxy.org/u/lukastribus)
#### Post date: [May 3, 2016, 8:13pm UTC](https://discourse.haproxy.org/t/bingbot-sni-handling-terminate-at-tls-layer/249/6 "2016-05-03T20:13:34Z")
To be more specific: when strict-sni is set and a invalid or no SNI value is set in the client\_hello, haproxy aborts the handshake by sending a fatal-level unrecognized\_name(112) alert as per [RFC6066 section-3](https://tools.ietf.org/html/rfc6066#section-3):
> If the server understood the ClientHello extension but
> does not recognize the server name, the server SHOULD take one of two
> actions: either abort the handshake by sending a fatal-level
> unrecognized\_name(112) alert or continue the handshake.
---
### Author:  [@jgelens](https://discourse.haproxy.org/u/jgelens)
#### Post date: [May 3, 2016, 8:54pm UTC](https://discourse.haproxy.org/t/bingbot-sni-handling-terminate-at-tls-layer/249/7 "2016-05-03T20:54:55Z")
Yep I confirmed that using wireshark. Haproxy behaves correctly. I did some more tests with bingbot and it’s behavior seems to be really inconsistent. Some SNI domains are working perfectly and others not. While it’s the exact same HAproxy config.
So it has to be something really weird on Bingbot ends and not my config in Haproxy. Therefore I consider this topic closed 🙂