haskell-tls / hs-tls Goto Github PK

When running Stackage, I got the following failure:

Test suite logged to: dist/test/tls-1.1.0-test-tls.log
hpc: can not find PubKey in ["./dist/hpc/mix/tls-1.1.0"]

I am getting this :

upgradeclient: HandshakeFailed (Error_Packet_unexpected "Alert [(AlertLevel_Fatal,BadRecordMac)]" " expected: change cipher")

I use http-conduit with client authentication. On the server side :

[Fri Nov 16 09:53:36 2012] [debug] ssl_engine_kernel.c(1934): OpenSSL: Write: SSLv3 read finished A
[Fri Nov 16 09:53:36 2012] [debug] ssl_engine_kernel.c(1953): OpenSSL: Exit: error in SSLv3 read finished A
[Fri Nov 16 09:53:36 2012] [debug] ssl_engine_kernel.c(1953): OpenSSL: Exit: error in SSLv3 read finished A
[Fri Nov 16 09:53:36 2012] [info] [client 10.2.1.167] SSL library error 1 in handshake (server guignol.it.int:8240)
[Fri Nov 16 09:53:36 2012] [info] SSL Library Error: 336130329 error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac

I suppose you need more data to debug this. What do you need ?

I think I have found a serious vulnerability in tls-extra in the
certificate verification code. It checks the certificate chain, but
doesn't seem to check the basic constraints of the individual
certificates.

This allows a owner of any signed certificate by an arbitrary CA to create
arbitrary other certificates for any CN. I recommend watching a talk about
SSL given by Moxie Marlinspike.

Hi, I might have found a couple of issues in TLS-extra. Do you have a GPG-key so that I can send you a more detailed report of the issues?

Hello, could you please add in a basic client/server?
Ideally in the debug examples, but in the haddock for examples would make a lot of sense no? Network.Socket.ByteString has examples.

Bonus points if you add cereal encoded types to make a basic protocol. Pattern matching <3

data Comm = Command1 | Command2 | Command3 | ...

Thanks.

In the package description for tls, it says:

Only core protocol available here, have a look at the http://hackage.haskell.org/package/tls-extra/ package for default ciphers, compressions and certificates functions.

But the package description for tls-extra says:

Deprecated in favor of tls

So it is not clear whether you recommend using tls-extra or not.

please apply patch that will add tests files

diff --git a/tls.cabal b/tls.cabal
index c0d5d8f..05e616c 100644
--- a/tls.cabal
+++ b/tls.cabal
@@ -25,6 +25,12 @@ stability: experimental
Cabal-Version: >=1.6
Homepage: http://github.com/vincenthz/hs-tls
data-files: README.md, TODO
+extra-source-files:

•                 Tests/Connection.hs
  

•                 Tests/Certificate.hs  
  

•                 Tests/Connection.hs
  

•                 Tests/PipeChan.hs
  

•                 Tests/PubKey.hs
  

  Flag test
  Description: Build unit test

This security fix seems to have caused a regression in checking the certificate of https://www.box.com/

One easy way to see the problem is using DAV's hdav command, which is here built using haskell-tls-extra 0.4.6.1:

joey@gnu:~/tmp/haskell-dav-0.3/dist/build/hdav>./hdav getprops --username=foo --password=foo https://www.box.com/dav/dne
hdav: HandshakeFailed (Error_Protocol ("certificate rejected: certificate is not allowed to sign another certificate",True,CertificateUnknown))

Checking the same url with Chrome, Firefox, and wget, none of them have a problem with its certificate chain. While I can't rule out the possibility that they're all vulnerable to the same hole that was fixed, it seems more lilkely that the fix made to hs-tls was buggy.

https://en.wikipedia.org/wiki/OCSP_Stapling

(This should be "wishlist", I can't tag it myself.)

Would it be possible to release a version of tls-extra that forwards all functionality from tls in a way that's (mostly) compatible with existing code?

Right now, many packages like network-conduit and yesod-platform depend on tls-extra (Cc: @snoyberg), and in the current state we cannot update tls in NixOS until all of those packages have updated their code and released a new version.

RFC 5246, Section 6.2.1 states:

The record layer fragments information blocks into TLSPlaintext
records carrying data in chunks of 2^14 bytes or less.  Client
message boundaries are not preserved in the record layer (i.e.,
multiple client messages of the same ContentType MAY be coalesced
into a single TLSPlaintext record, or a single message MAY be
fragmented across several records).

Receiving.hs does not conform to this instruction, nor can any function with the type

    processPacket :: Context -> Record Plaintext -> IO (Either TLSError Packet)

possibly do so. While change_cipher_spec messages are a single byte and application_data records have no structure, so therefore messages with these content types cannot possibly be fragmented, it is possible for alert and handshake messages to span multiple records or for multiple such messages to be contained within a single record. The current implementation of processPacket does not allow handshake messages to span record boundaries, and expects a precise 1:1 relationship between alert messages and alert records.

In order to produce spec-conformant behavior, the signature of processPacket needs to change somehow to reflect the arbitrary many-to-many relationship between records and messages. Conduits or Machines might provide a suitable abstraction for this.

Hello,

I'm using your TLS library through http-conduit. When cancelling the thread dealing with HTTP transfers while a connection is established, I often get an exception looking like this:

TlsException (HandshakeFailed (Error_Misc "thread killed"))

TlsException (HandshakeFailed (Error_Protocol ("certificate rejected: thread killed",True,CertificateUnknown)))

This is problematic, as it makes it hard to distinguish between connection / IO errors and a simple cancellation request. It seems the original exception is gone and converted to a string, and there is no type safe way to detect it was a ThreadKilled. Especially since there seem to be several different errors which could potentially encapsulate it, and even if I handle all of them, a new one might be introduced, silently breaking cancellation.

I don't know anything about TLS or how http-conduit uses it, but it seems to me just letting a ThreadKilled exception propagate would be much more useful than wrapping it somehow in an unrelated error.

When a connection is establish, spec allows to receive a new handshake to establish a new record context, and still receive appdata on the current established record context.

Not currently aware of any implementation that would allow to send data when the handshake is in progress.

A user reported this to me as an issue with haskellers.com. I can reproduce this with tls-simpleclient. When I run:

tls-simpleclient verifier.login.persona.org 443

I get the result:

tls-simpleclient: HandshakeFailed (Error_Packet_unexpected "Alert [(AlertLevel_Fatal,BadRecordMac)]" " expected: change cipher")

Connecting with curl produces no problem.

Sorry for two reports in as many hours, hopefully this one isn't a garbage report ;).

Ran the test suite while investigating http-conduit (@snoyberg) issue 63 (https://github.com/snoyberg/http-conduit/issues/63).

Marshalling:
Header: [OK, passed 100 tests]
Handshake: [OK, passed 100 tests]
Handshakes:
setup: [OK, passed 100 tests]
initiate: [Failed]
Falsifiable with seed -3432012487283935254, after 1 tests. Reason: Exception: 'got "\190\246z!\220\251xi2U\243Od0P\131\240\171B\231\208\205\134\168\153\DC1\US\249\DC4KB\176" but was expecting "\190\246z!\220\251xi2U\243Od0P\131\240\171B\231\208\205\134\168\153\DC1\US\249\DC4KB\176\236.K\174bD\218wAeK\164\138\203K\173\253\f,@s\165~\214\DC1\EOT\161\200?p)\175&g\244\252&3@2qI\ACK\174[|\135\158&3o\201\179/\240_\v(%\ESC\163\205\RSU\253\v\182\240p\ESC\169\CAN\185rvR\133\178\131\161\193%\SO\212y\247y7\166\DC2T\134\t\EOT\166\130\194\178\r\209H%&\151\232\199\212\191\161\170c_\158\204\227\200N\245I\247\228T\176\145\229\151w\239Z8\155\170@]\203\199V\140\145\203\143DL\204\226a|\158*zYZ\250Az\218\160\226\236O\213\220\SYNY9\DC2\SI\221\200\163\150\248DNf9\246\177sy\184\151I\191~M\239\179\185\144i\244\FS\231\228\182(\131\175\236\a\173\228\226@\SOH\152\136\160\157\193\144T\200\205CA\nT\DC3~1\137$\v"' renegociation: [Failed] Falsifiable with seed 3986042519013856110, after 1 tests. Reason: Exception: 'got "\SI2\163\201X}\SUBtC;R\199\215{Z\149\172\154\214\240,\161\203\153\243\219\189\244\SOH\US\235u" but was expecting "\SI2\163\201X}\SUBtC;R\199\215{Z\149\172\154\214\240,\161\203\153\243\219\189\244\SOH\US\235u\232\130)\204\174\248M\234\253\SUB\205Dr\ETX\209\142\133\229\ESC3\238\248X\NUL\146\&0\131\253\158 p\179\195\145\STX\248\188\160>\247\241F\156\255\242n\189\168gZS_\205\135\182\173Z\185\151\189\244\229$n\136Y\NAK\205\189\232\140&4\138\SUB\128\178i\165~\b\220x\230\238D\DC3E\247M<\237e\EM\RS\206&5\202\FS\142\168\247,wX\230\160p\166N\141G<.\142]v\189\157%\210\210\198\174\ESC/\156J\n\153Q\EOT\DC2J\167DGD\173{\130<\194\191\193\206\164\v\234\254\190\197u\ETB w\136py\174\172\254\249\225\131\241\235\153\156\175<Q\SI\NULu\201\162&4"\174\130'$d\150\212\227\227\196qK\174\205\236\186j\182\f\195\195\GS\220\161\226\180\SI\132<\r\155&8\252@4\202\ETBD\190\USXW\191y"'
resumption: [Failed]
Falsifiable with seed 8803514947565563632, after 1 tests. Reason: Exception: 'got "?{]C\v8\ENQ\183\222\171&5\236\253/\226\186t\v?\245\176\168K\155\199\215sh\169\216\STX" but was expecting "?{]C\v8\ENQ\183\222\171&5\236\253/\226\186t\v?\245\176\168K\155\199\215sh\169\216\STXL\243\163\166\191W[\DLE\201\207\229\EOT\231x \150\217sg t\250\v\US\193@\233_\EOT\147\CANWX\b7\NUL\154"]z7\187\221\ESC\220&7\177\SYN\b\210&\253\147\217S\210&6\229\138\146{\187&1k]\229\DLE\154y\172\143\190\151o\208\227\184\DC2i\217\220\NULj\SYN\HXC\200'[\CAN\174D\233\GS\169^\160&5\248G\DLEG\153"\231\151\237&d<?]3\193\141M(\148\SI\DC46\144F\138\160Q\163}EM\248\DEL\160J\224\132\183xOk\190zc\194tU\205b\STXW\223\DELAh\240\140&62\238&3\178g7rJ)\229\237\r;\238\248\171\151o\v*%\229\229S\177\165n\133\188\f\164\181\188@\193\140\191\245\247:\239&3\f\181\227$\152\197\ACK\DC4\DC1\241\180\209U\154\SO\232\239l@d^"'

     Properties  Total

Passed 3 3
Failed 3 3
Total 6 6

Thanks for suggesting this test!

In an e-mail to me, Vincent suggested a system for "plugin" callbacks. This would enable users of hs-
tls to get otherwise hidden debugging information, such as handshake data, through the means of callback functions.

(I personally need the FinishedData value from Network/TLS/Struct.hs.)

In some applications it's expected that a given connection will use TLS, but there's no way to know for sure that the other side will respond with a TLS response instead of a plaintext response of some sort (the same host/port will use TLS sometimes but not others, e.g. for some varieties of connection error). At present I can find no way to handle this kind of situation gracefully with hs-tls, as hs-tls wants control of the socket and there seems to be no way to recover the original, non-TLS, data stream received when the handshake subsequently fails.

The existing logging capabilities come close to being sufficient, but they provide no way to find the values of some of the raw bytes received.

Could something along these lines (e.g. a logging callback for the raw bytes of the handshake in their entirety) be implemented?

Hi Vincent,

The following code throws an exception with both http-conduit and http-enumerator:

simpleHttp "https://browserid.org" >>= print

I have tls version 0.8.5 installed. I know the connection has worked in the past; you can log into Haskellers.com via BrowserID, for example.

Let me know if I can provide any more information.

Thanks

As a result of Heartbleed*, we recently reissued our certificates on www.fpcomplete.com, using the same CA we had previously. Every since then, we have received user complaints that some client side tools get unknown CA errors when connecting to www.fpcomplete.com. I ran tls-simpleclient, and the last line of output was:

tls-simpleclient: HandshakeFailed (Error_Protocol ("certificate has unknown CA",True,UnknownCa))

Let me know if I can provide you with any more information.

* Thanks to the tls package, we were mostly insulated, but we still used Amazon's ELB, which was affected.

In tls-0.9.0, recvData has the following signature:

recvData :: MonadIO m => TLSCtx c -> m Bytes

However, Bytes is a type alias in the hidden module Network.TLS.Struct. Fortunately, users can still use recvData by treating Bytes exactly as ByteString.

Hi!

I'm currently finding myself needing to catch not only TLSError, but also HandshakeFailed. Additionally, you have two other Exception types: ConnectionNotEstablished and Terminated. Using your library, it's not entirely clear what can be thrown, and when. Would it be possible to wrap these two exceptions into TLSError, thus making the API more understandable, and slightly easier to work with, allowing for a more straight-forward catch logic?

Thanks for a great library!

c686d8d introduced this code in Network.TLS.Core.sendPacket:

withEmptyPacket <- usingState_ ctx needEmptyPacket
when (isNonNullAppData pkt && withEmptyPacket) $ sendPacket ctx $ AppData B.empty

  where
            isNonNullAppData (AppData b) = B.null b
            isNonNullAppData _           = False

This will loop forever if withEmptyPacket is True, because isNonNullAppData will always be True.

Hi,

I'm using a library that uses http-enumerator. I'm having an issue with the library, as it is throwing:

*** Exception: error unexpected packet: pHandshake [ServerHelloDone]

Which is being thrown in Network/TLS/Core in the `recvData' function.

I've tried with both the version on hackage 0.7.2 and also the version on hackage, 0.7.99

Rob Stewart

Please add the SNI extension to the TLS handshake; https://musicbrainz.org/ now delivers the coverartarchive.org certificate if SNI is not used, and this leads to a rejection:
("certificate rejected: FQDN do not match this certificate",True,CertificateUnknown))'

I'm getting the following failure when building tls-0.5. I believe I am using the latest versions of all of tls-extra's dependencies.

Network/TLS/Extra/Cipher.hs:77:48:
    Couldn't match expected type `Data.Vector.Unboxed.Base.Vector
                                    GHC.Word.Word8'
                with actual type `Data.Vector.Storable.Vector GHC.Word.Word8'
    In the first argument of `Vector.toList', namely `v'
    In the second argument of `(:)', namely `Vector.toList v'
    In the second argument of `(:)', namely `y : Vector.toList v'

Network/TLS/Extra/Cipher.hs:82:27:
    Couldn't match expected type `Data.Vector.Storable.Vector
                                    GHC.Word.Word8'
                with actual type `Data.Vector.Unboxed.Base.Vector GHC.Word.Word8'
    In the return type of a call of `Vector.fromList'
    In the expression: Vector.fromList l
    In the expression: (Vector.fromList l, x, y)

Network/TLS/Extra/Cipher.hs:83:27:
    Couldn't match expected type `Data.Vector.Storable.Vector
                                    GHC.Word.Word8'
                with actual type `Data.Vector.Unboxed.Base.Vector a0'
    In the return type of a call of `Vector.fromList'
    In the expression: Vector.fromList []
    In the expression: (Vector.fromList [], 0, 0)

I would be interested in adding support for client certificates to the tls package. I've seen that you already have some infrastructure in place for that, but that it is currently disabled.
Before I start to work on that: have there been any big challenges in adding client certificate support, or have you just postponed it because of lack of need or lack of time.
So if you think it would be a good idea to work on that, or if you know of someone else who is doing it, drop me a line -- either here or at [email protected].
Thanks for your good work!

I took the .pem key file that I was using with openssl, which had a passphrase (so encrypted with DES or something). Putting this as the key file caused a segfault somewhere in tls code. Probably this should instead print out an error saying that encrypted private keys are not supported.

tls-extra:Network.TLS.Extra.Certificate
****************** certificate verify chain doesn't yet work on your platform **
********************
please consider contributing to the certificate package to fix this issue

Got this error when trying to send an email via amazon SES w/ mime-mail-ses on windows server 2008. How can I contribute to fix this problem? OR has it already been fixed and the ses pkg is using an outdated driver?

Latest tls requires cereal >= 0.4.0.0 because the Data.Serialize.Get.Result constructor changed.

The NPN extension functions defined in Params can be split into server and client params.

It's always the server that suggests a number of protocols possible to use, and the client that chooses.

On other words;
onSuggestNextProtocols can be moved to ServerParams.
onNPNServerSuggest can be moved to ClientParams.

  , onSuggestNextProtocols :: IO (Maybe [B.ByteString])
  , onNPNServerSuggest :: Maybe ([B.ByteString] -> IO B.ByteString)

Hi,

Sorry if this is the wrong venue for this - feel free to redirect me if IRC / email is better.

I'm trying to use a certificate with keter/warp-tls, and it's failing with "no ciphers available with those parameters", which is being triggered because the RSA key is not passing canEncryptRSA (in Network.TLS.Context) because in credentialsCanDecrypt (in Network.TLS.Credentials) the extensions are ExtKeyUsage [KeyUsage_keyCertSign,KeyUsage_cRLSign], which cause a failure.

To be honest, I don't know what this means (just blindly tracking down the failure), so I'm not sure if this is a feature request, a bug, or a configuration thing I can change (can I change the certificate to not have these extensions?). I'm right now double proxying (nginx to do ssl, proxied to keter, which proxies to my application), and there are some configuration problems with that, so I'd really like to get tls to handle the ssl, but it obviously isn't working right now!

This is rather a question than an “issue”, but I wouldn't know of a way of asking it to the people who are involved without pestering the author exclusively. I'm trying to talk to an IMAP-over-SSL server (dovecot, as it happens) combining hs-tls with HaskellNet. It looks like a really easy thing to achieve:

import Crypto.Random.AESCtr as Random
import Network.HaskellNet.BSStream
import Network.HaskellNet.IMAP
import Network.TLS
import Network.TLS.Extra

myParams = do
    cert <- fileReadCertificate "mycert.pem"
    return $ defaultParamsClient
           { pCertificates = [ (cert, Nothing) ]
           , pCiphers      = ciphersuite_all
           -- , pConnectVersion = TLS10
           }

connect = do
    p <- myParams
    g <- Random.makeSystem
    ssl <- connectionClient "example.com" "993" p g
    handshake ssl
    let b           = ctxConnection ssl
        plaintext   = BSStream
            { bsGetLine = recvData ssl   -- Not sure yet about correctness
            , bsPut     = backendSend b  -- Ditto
            , bsGet     = backendRecv b
            , bsFlush   = backendFlush b
            , bsClose   = bye ssl >> contextClose ssl
            , bsIsOpen  = return True    -- Not used anyways, afaics
            }
    imap <- connectStream plaintext
    return (ssl,plaintext,imap)

Calling connect from ghci, everything looks fine:

    ghci> (ssl,plaintext,imap) <- connect

Any further operation, however, provokes a fatal TLS error; for example,

    ghci> capability imap
    *** Exception: Terminated True "received fatal error: ProtocolVersion" (Error_Protocol ("remote side fatal error",True,ProtocolVersion))

The relevant lines from the server log, minus IPs:

[...]
imap-login: Debug: SSL: where=0x20, ret=1: SSL negotiation finished successfully
imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully
imap-login: Warning: SSL alert: where=0x4008, ret=582: fatal protocol version
imap-login: Warning: SSL alert: where=0x4008, ret=256: warning close notify
imap-login: Disconnected (no auth attempts in 1 secs): user=<>, TLS: SSL_read() failed: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number, session=<6PT+9FrXHwBQj0IM>

Maybe I'm just doing something stupid somewhere; or can hs-tls actually get somewhat confused about which protocol version it is talking?

Hello vincent,

thank you for this great package, very helpful in my daily work.

I have had a good experience using it with OpenSSL-based certificates, however it does not seem to be good friend with GNUTLS-based content.

For exemple, this SO issue is still current : http://stackoverflow.com/questions/7941064/how-to-generate-a-self-signed-certificate-for-use-with-network-tls

Also, even with GNUTLS 3.0.4 certtool, the tls package is unhappy and will fail to verify the chain, with an error "chain doesn't match each other". We have checked with various tools that the chain was actually valid. Again, no problem with OpenSSL-based content, but GNUTLS is a good tool that certainly deserves some more love.

regards,

Curious how come this is set to default, seems like it would be better the other way around.

This issue manifests itself in combination with http-enumerator, as I'm not sure who is the culprit, I don't know where exactly this issue belongs

Please see snoyberg/http-enumerator#44 for more details

If support were to be added for http://www.ietf.org/rfc/rfc6091.txt, what would be right right way to do it? I expect at least some changes would have to be made in this package, though it would be reasonable to put as much as possible in a separate module.

I have a small example file I've made that fails on the handshake with some servers. The error returned is:

HandshakeFailed (Error_Packet_Parsing "Failed reading: certrequest distinguishname 
not of the correct size\nFrom:\thandshake\n\n")

Here is a gist of file I used. Using both irc.oftc.net and chat.freenode.net fail during the handshake. Openssl also gives some errors, but manages to complete the connection.

verify error:num=19:self signed certificate in certificate chain

verify error:num=20:unable to get local issuer certificate

Basically TLS for datagram protocols (e.g. UDP). RFC4347 aims to present not a new protocol but a series of deltas from TLS1.1.

OpenSSL has DTLS support for server and client, which can be used for testing and reference.

Server:

openssl s_server -dtls1

Client:

openssl s_client -dtls1

add EllipticCurve (10) and EcPointFormats (11)

If the only reasons to put all of the code into the IO monad are isolated to Backend and error logging, why not make that generic and pull all of the code upward?

A user supplies their own IO/Logger monad (for instance, Server ProxyFast () ByteString (EitherT [SomeException] m) a from pipes or something using HsLogger) and this will throw them down to IO if they're using an IO-backed Backend... but might also leave them up in a more pure monadic context if so desired.

This would make the library more useful in more contexts (mine for instance) and also much, much easier to test.

This would be a fairly easy refactoring, but it'll break some code. I'd be happy to experiment with it, but I wanted to ask first to see what the sentiment to such a change would be.

Cheers!

Subject says it all. :-)

Latest version of tls from hackage can't connect to planet.gnome.org

tls-simpleclient -d -v planet.gnome.org 443
sending query:
GET / HTTP/1.0



debug: >> Handshake [ClientHello TLS12 (ClientRandom "\169g\162\SUB\215\189\206\143\&0\139&8\159*\143f\191\229\&6d\168\232Ew\NAK\148<\176m\223.\169") (Session Nothing) [107,103,57,51,56,50,47,53,4,5] [0] [(0,"\NUL\DC3\NUL\NUL\DLEplanet.gnome.org"),(65281,"\NUL")] Nothing]
debug: << Alert [(AlertLevel_Warning,UnrecognizedName)]
debug: >> Alert [(AlertLevel_Fatal,InternalError)]
tls-simpleclient: HandshakeFailed (Error_Misc "user error (unexpected type received. expecting handshake and got: Alert [(AlertLevel_Warning,UnrecognizedName)])")

I'm always getting an exception (Error_EOF) when reading the response from our API. I'm using http-conduit-2.0.0.8 and @snoyberg suggested that the exception originates from tls: snoyberg/http-client#36

The issue can be reproduced using the following code:

{-# LANGUAGE OverloadedStrings #-}
import Network.Connection
import qualified Data.ByteString.Char8 as S8
import Data.Default (def)

main :: IO ()
main = do
    context <- initConnectionContext
    conn <- connectTo context ConnectionParams
        { connectionHostname = "www.digipost.no"
        , connectionPort = 443
        , connectionUseSecure = Just def
        , connectionUseSocks = Nothing
        }
    connectionPut conn "GET /post/api HTTP/1.1\r\nHost: www.digipost.no\r\n\r\n"
    let loop = do
            bs <- connectionGetChunk conn
            if S8.null bs
                then return ()
                else do
                    S8.putStr bs
                    loop
    loop

Any idea what could be causing this?

hello

my ubuntu system did not have the "ca-certificates" package installed. when i used "http-enumerator" module (which uses "tls" module) on this system it would fail with:

Error during enum: error unexpected packet: Handshake [ServerHelloDone]

this error message is not helpful. i spent the next two hours checking every difference between this system and another seemingly identical system until i finally found the error. when i installed the "ca-certificates" package everything suddenly worked. a better error message would have saved me this precious time. thanks!

ALPN is similar to NPN, but reverses who suggests the next protocol and who chooses.

http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-05

At the moment, you support renegotiation, but not secure renegotiation. As a result, you are likely vulnerable to
http://en.wikipedia.org/wiki/Transport_Layer_Security#Renegotiation_attack
Since it would take a while to implement secure renegotiation, and renegotiation isn't a commonly used feature, it would be nice if there was either a config setting to turn it off, or it got removed.