No implement crypto binding

[sorz]

Must verify certHash and macHash on sstpMsgCallConnectedReceived() to prevent MITM attack.

[sorz]

Certificate hash is verifed since 1aa9a51.

For macHash, SSTPd have to parse and inspect LCP and authentication protocol
(MS-CHAPv2 & EAP) data flow. These are what we haven't done.

[tisj]

Hi @sorz,

To my understanding, the Higher Layer Authentication Key (HLAK) can not be snooped/derived from the authentication data flow (as the keys are not transferred over the wire). They can only be obtained from the process that created/maintains them (thus ppp daemon; or possibly in linux from the ppp_mppe kernel driver).

The sstp-client project dealt with the same difficulty, and implemented a solution by creating a special ppp plugin (called sstp-plugin), that snoops outgoing ppp packets for (CHAP) authentication success, if then the mppe send/recv keys are set by ppp it will expose them to the sstp-client program (by means of a unix socket), allowing to calculate the crypto bindings.

I made an implementation for sstp-server using that same technique (reusing their ppp plugin, and adding a unix socket to listen on). Thus it adds crypto binding support for both SHA-1 and SHA-256 operations, for MS-CHAPv2 and EAP-TLS (using MPPE Master{Send,Recv}Key). Normal EAP uses Client Master Session Key and Server Master Session Key, which are not captured by the sstp-plugin.

The implementation has been tested with the linux sstp-client, and microsoft sstp clients (w8 and w10). Let me know if you are interested...

[sorz]

Thanks! You are right, these keys must not be snoopsable otherwise the crypto binding is meaningless.
PR is welcome!