Lighttpd connections.c SSL routines:SSL3_GET_CLIENT_HELLO (no shared cipher) etc



  • Helle all,

    I'm running 2.1-RELEASE (amd64) built on Wed Sep 11 18:17:48 EDT 2013 FreeBSD 8.3-RELEASE-p11 on a basic Intel(R) Pentium(R) 4 CPU 3.20GHz2 CPUs: 1 package(s) x 1 core(s) x 2 HTT threads (a Dell Dimension retired desktop system with 3 NIC's).

    I have a WAN (pppoe) + LAN (+switch+several Office PC's, printers, NAS, and others) + OPT (Wifi Portal -> switch + 4 AP's Wifi Portal for our clients - we have a hotel).
    No packages - accept for NUT for my UPS support.

    I used this excellent how-to with a StartSSl certificate:
    PFsense 2.1 MultiCP and https with Windows Radius Guide 
    User authentication is 'local'.

    After activating the 'https' login procedure on the portal interface, I saw these error logs when clients enter the portal:

    lighttpd[23135]: (connections.c.305) SSL: 1 error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

    lighttpd[89480]: (connections.c.305) SSL: 1 error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher

    lighttpd[23135]: (connections.c.1731) SSL: 1 -1 error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

    Mostly, they are multiple of each of these lines.

    The Captive portal works - clients use it http://www.test-domaine.fr/munin/dyndns.org/brithotelfumel.dyndns.org/portalusers.html
    This is NOT what I mean  Captive Portal https login page stopped working on pfsense 2.1 - all seems to work well for me.

    It seems to me that these lighttpd errors happen when clients log in (are getting disconnected). Some SSL noise because the start surfing to (example) https://www.google.com and get directed to https://portal.brit-hotel-fumel.net

    Is there a GUI solution to shut down the "lighttpd errors log" (I know it wasn't there before, so we didn't care).

    Anyway …. 2.1, I'll keep it. It's ready for production for me.
    Thumbs up  :)



  • Those errors come out usually when you forward HTTP(port 80) traffic to SSL(port 443) traffic.

    Probably need to be checked what the forwarding rules generated are doing there to tell for sure.

    Normally, apart overhead there is no problem with that.


Log in to reply