| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We re-wrote WinTLSSession::writeData. The major points are:
* Buffer is now preallocated once handshake is finished. Previously,
they are allocated each time when we send one TLS record.
* Schannel uses header, body and trailer for each secBuffer. Now we
send them off at once using WSASend which is windows counterpart of
sendv. Previously, we do memmove if some of them are truncated.
* We don't try to send application data in
WinTLSSession::closeConnection, since semantically we need same
application data used to create TLS record before. Using 0 length
data to finish sending buffered data looks like a hack.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
WinTLSSession buffers received decrypted data into its own buffer. If
read is requested, it copies the data from its buffer. But if
requested buffer size is less than decrypted buffer, some of the data
is left in the buffer. Previously, we had no facility to check the
existence of this pending data. If this data is the last requested
data from remote server, we may end up waiting for read event even if
we have already data in our buffer, which may cause hang. This commit
fixes this issue by introducing function to return the buffered length
in TLSSession. SocketCore also provides the same function, which
delegates to TLSSession object.
|
| | |
|
| | |
|
| |
|
|
|
| |
Also fiddle a bit with the WinTLS implementation, forcing "strong"
crypto only for > SSLv3.
|
| |
|
|
| |
Fixes GH-277
|
| |
|
|
| |
Fixes gh#277
|
| | |
|
| |
|
