Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"A sleep(1) is put into all SSL_read() and SSL_write() calls..."

bugs.python.org

Post reply on HN
Print view View original

11–20 of 52 posts

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#11

Post by fexl »

JoachimSchipper wrote: post #8
typedef_void wrote: post #6

Earlier quoted context omitted.

on second thought, my comment makes little sense, if they wanted noisy sleep, it should be something like sleep(func(rand()))

That makes no sense either, an attacker can usually average such things out. Besides, there are better (faster) ways to guard against timing attacks.

Besides, I see no evidence that the sleep was intended to thwart timing attacks. It looks like it's all about easing the debug process somehow.

Incidentally, the primary problem here is not the mere presence of a debug flag that governs a sleep, it's the fact that PySSL_SSLdo_handshake sets that debug flag. Right?

In other words, it's not a bug in OpenSSL itself, but rather the Python wrapper for OpenSSL. That's how I understand it.

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#13

Post by fourneau »

kqr2 wrote: post #7

It looks like someone forgot to remove the "speed-up loop". http://thedailywtf.com/Articles/The-Speedup-Loop.aspx

That's both hilarious and frightening all at once. Luckily static analysis tools catch that kind of stuff very easily now...

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#15

Post by jakevoytko »

typedef_void wrote: post #5
po wrote: post #4

I bet removing this causes something somewhere to break.

is sleep(1) noisy? if so, it might be vs timing attacks

Sleep(1) is very noisy on Windows machines. The time slice given by default is ~15-20ms [1], and calling Sleep(This crummy Sleep() implementation has some nice effects on programmers. Those who like to solve problems with lots of copy/paste code are forced to think about using proper synchronization primitives when running high resolution loops that wait for events, or their code just won't run very fast.

[1] http://social.msdn.microsoft.com/forums/en-US/clr/thread/fac...

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#16

Post by bd »

jakevoytko wrote: post #15
typedef_void wrote: post #5

Earlier quoted context omitted.

is sleep(1) noisy? if so, it might be vs timing attacks

Sleep(1) is very noisy on Windows machines. The time slice given by default is ~15-20ms [1], and calling Sleep( This crummy Sleep() implementation has some nice effects on programmers. Those who like to solve problems with lots of copy/paste code are forced to think about using proper synchronization primitives when running high resolution loops that wait for events, or their code just won't run very fast. [1] http:/…

Aha, so that's probably why JavaScript timers on Windows have around 15ms accuracy:

http://ejohn.org/blog/accuracy-of-javascript-time/

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#17

Post by JoachimSchipper »

fexl wrote: post #11
JoachimSchipper wrote: post #8

Earlier quoted context omitted.

That makes no sense either, an attacker can usually average such things out. Besides, there are better (faster) ways to guard against timing attacks.

Besides, I see no evidence that the sleep was intended to thwart timing attacks. It looks like it's all about easing the debug process somehow. Incidentally, the primary problem here is not the mere presence of a debug flag that governs a sleep, it's the fact that PySSL_SSLdo_handshake sets that debug flag. Right? In other words, it's not a bug in OpenSSL itself, but rather the Python wrapper for OpenSSL. That's how…

Yes, exactly.

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#19

Post by jamesseda »

ars wrote: post #14
jamesseda wrote: post #12

I have been working on a replay tool in python. I had to add sleeps because it was sending packets faster than the NIC could send them in order.

That's not a reliable way to do that. It should block.

it is actually more reliable to sleep than to block. by definition blocking is unreliable because you don't know exactly when it will unblock. You do know when a sleep will end though. I also want a variable delay between writes.

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#20

Post by ars »

jamesseda wrote: post #19
ars wrote: post #14

Earlier quoted context omitted.

That's not a reliable way to do that. It should block.

it is actually more reliable to sleep than to block. by definition blocking is unreliable because you don't know exactly when it will unblock. You do know when a sleep will end though. I also want a variable delay between writes.

Uhhh. I think you need to study this topic some more.

> it is actually more reliable to sleep than to block. by definition blocking is unreliable because you don't know exactly when it will unblock.

A block will end when the nic can handle more data. You can't just wait a second and assume the nic can handle the data. That's where the "unreliable" part comes in. You assume it can handle the data, but you are not checking. And the way to check is either by polling, blocking, or receiving a signal. Waiting is not a way to check.

> You do know when a sleep will end though.

It makes no difference that you know when the sleep will end. It's irrelevant - all you care about is can the nic accept more data or not.

> I also want a variable delay between writes.

If you want variable delays then do that, but that has nothing whatsoever to do with making sure the nic doesn't lose data.

Post reply on HN