Fix bug in server parsing point formats extension

There is only one length byte but for some reason we skipped two, resulting in
reading one byte past the end of the extension. Fortunately, even if that
extension is at the very end of the ClientHello, it can't be at the end of the
buffer since the ClientHello length is at most SSL_MAX_CONTENT_LEN and the
buffer has some more room after that for MAC and so on. So there is no
buffer overread.

Possible consequences are:
- nothing, if the next byte is 0x00, which is a comment first byte for other
  extensions, which is why the bug remained unnoticed
- using a point format that was not offered by the peer if next byte is 0x01.
  In that case the peer will reject our ServerKeyExchange message and the
handshake will fail.
- thinking that we don't have a common point format even if we do, which will
  cause us to immediately abort the handshake.
None of these are a security issue.

The same bug was fixed client-side in fd35af15

ChangeLog

@@ -4,7 +4,9 @@ mbed TLS ChangeLog (Sorted per branch, date)
 
 Bugfix
    * Fix warning when using a 64bit platform. (found by embedthis) (#275)
-   
+   * Fix off-by-one error in parsing Supported Point Format extension that
+     caused some handshakes to fail.
+
 Changes
    * Made X509 profile pointer const in mbedtls_ssl_conf_cert_profile() to allow
      use of mbedtls_x509_crt_profile_next. (found by NWilson)

library/ssl_srv.c

@@ -299,7 +299,7 @@ static int ssl_parse_supported_point_formats( mbedtls_ssl_context *ssl,
         return( MBEDTLS_ERR_SSL_BAD_HS_CLIENT_HELLO );
     }
 
-    p = buf + 2;
+    p = buf + 1;
     while( list_size > 0 )
     {
         if( p[0] == MBEDTLS_ECP_PF_UNCOMPRESSED ||