#twisted

Tickets pending review: https://tm.tl/#8894, #8900, #6800, #8922 (glyph), #8325 (the0id), #8934, #8920

hawkowl reviewed <https://tm.tl/#8934>; - remove mac builds from travis (assigned to hawkowl)

hawkowl closed <https://tm.tl/#8934>; - remove mac builds from travis

Tickets pending review: https://tm.tl/#8894, #8900, #6800, #8922 (glyph), #8325 (the0id), #8920

Tickets pending review: https://tm.tl/#8894, #8900, #6800, #8922 (glyph), #8325 (the0id), #8920

Tickets pending review: https://tm.tl/#8894, #8900, #6800, #8922 (glyph), #8325 (the0id), #8920

so I installed python-qt4reactor. the man pages say you can do reactors.installReactor('qt4'), but that gives the error: twisted.application.reactors.NoSuchReactor: 'qt4'

if I just try reactors.installReactor('qt') it says the same thing and 'qtreactor is no longer a part of Twisted due to licensing issues.

is there some way to fix this stupid error

I;m having an issue where a twisted.web.resource based http server will not read TLS(SSL) records that arrive in the same TCP segment as a TLS heartbeat

strace shows that python received the data

but the server doesn't process it

if there is a time delay between the heartbeat and the application data record, everything works fine

If I look at the strace, it's waiting for more data

I'm guessing this is an issue in TLSMemoryBIOProtocol or the underlying PyOpenSSL layer

Tickets pending review: https://tm.tl/#8894, #8900, #6800, #8922 (glyph), #8325 (the0id), #8920

TLSMemoryBIOProtocol doesn't appear to handle reads/writes correctly, but I may be completely wrong about this

vdog: what's the issue you're seeing?

vdog: do you have an example program that reproduces it?

runciter: I just have a simple twisted.web.resource based server using TLS that receives HTTP requests and prints the body to the terminal

runciter: if the client sends the server a TLS heartbeat and a TLS application record in the same TCP segment, the http server fails to react to the application data

runciter: strace shows that the server reads the data, but then attempts to read more (which there is none.. the HTTP response should follow)

vdog: i see - how do you send the data and heartbeat at the same time?

runciter: The client is a program written in C, and it calls SSL_heartbeat() followed by SSL_write(). I thing Nagles algorithm is enabled so it coalesces them together at the TCP layer

vdog: can you pastebin the C code you have so i don't have to rewrite it myself :)

vdog: better yet, file a ticket in trac with the C code

alright maybe I can use the openssl s_client to do this

we won't judge the quality of the C code! don't be worried

runciter: I was looking in TLSMemoryBIOProtocol and it doesnt handle the WANT_WRITE case anywhere

that strikes me as strange, but I don't know the architecture of the python stack on top of OpenSSL

but that case should always be handled

somewhere in the stack

vdog: SSL_WANT_WRITE is for an openssl managed socket; BIOs don't raise it

they're in memory, so you just write to them

I see

you then write the bytes to the socket as you would any other bytes

now you will get SSL_WANT_READ, because the BIO can't construct a TLS message from incomplete data

vdog: flushSendBIO is where the writing to the transport (taking encrypted TLS messages out of the BIO and putting them on the socket) happens

vdog: please a ticket with your C code -- it'd be really helpful!

vdog: Yeah I am super interested to fix this bug

glyph: I'm trying to make a bash script to do it with openssl s_client

vdog: the heartbeat ought to just stick a heartbeat response into the send BIO

glyph: it does

glyph: but it doesnt continue reading from the received buffer

vdog: Is your C program properly checking the results of send() ? can you pastebin it?

glyph: strace shows that python received the entire TCP payload

from the client

vdog: so, the _most_ useful form of PoC would be a Python program that uses pyOpenSSL to generate some bytes and stuff them into a TLSMemoryBIOProtocol without a real socket anywhere

vdog: we could turn that into a unit test pretty easily

glyph: I'm not that talented, and trying to push out a research paper this week, sorry :(

oh :( looks like heartbeating isn't bound https://github.com/pyca/pyopenssl/search?utf8=✓...

vdog: It wouldn't be hard if the wrapper were already present, but I guess that's going to involve spelunking through too many levels (cryptography, do a cryptography release, pyopenssl, do a pyopenssl release, bump twisted's dep vers)

vdog: at what point in openssl does the response get buffered? just as soon as you call bio_write?

how do you mean?

I should note that I don't know much of anything about any python libraries, but I know a bit about OpenSSL (the C library)

but I don't use BIOs

vdog: if you happen to be familiar with the implementation; bio_write stuffs some network-received bytes into a buffer for OpenSSL. Does it react to them immediately and put stuff into the write buffer, or does it enqueue them to be processed at some later point, like when calling bio_read?

oh.

Well, you probably use a socket BIO :)

BIOs are just how openssl does I/O.

this is a "memory BIO"

but I never explicetly touch BIOs

right.

I am aware of them, though :)

yeah I'm not seeing how this would be possible

_flushReceiveBIO is called at the end of every dataReceived, and it processes _all_ the buffered application data

I also can't search for "openssl heartbeat function" without getting a page full of heartbleed articles :)

loganrun: hi! to answer *your* question, 'pip install qtreactor'

oops sorry

qt5reactor

loganrun: https://pypi.org/project/qt5reactor/

vdog: okay are you just having me on

vdog: SSL_Heartbeat is not a real API https://www.google.com/search?sitesearch=www.op...

literally not listed on https://www.openssl.org/docs/man1.1.0/ssl/ either

openssl doesn't have real documentation

it has a collection of garbage man pages

for a small subset