8

I'm having a lot of trouble with CF10's CFHTTP at the moment.

First, my test script:

<CFSET results = arraynew(1) />
<CFLOOP from="1" to="10" index="idx">
    <CFSET timer_start = getTickCount() />
    <CFHTTP url="https://www.google.de" method="get" result="test" />
    <CFSET arrayappend(results, (getTickCount()-timer_start)/1000 & " s") />
</CFLOOP>
<CFDUMP var="#results#" />

10 CFHTTP calls in a row, the time they take gets pushed to an array; that's all.

Results of our CF9 server:

CF9 CFHTTP TEST RESULTS

Results of our CF10 server:

CF10 CFHTTP TEST RESULTS

Results of our CF10 server with 5 sec delay between CFHTTP calls:

CF10 CFHTTP TEST RESULTS WITH DELAY BETWEEN CALLS

I already read on the forum and Shilpi's Blog that the reason could be that the Linux server runs out of entropy. I checked that with watch --interval=0.1 cat ... while my test script ran but it never dropped far under 4k (with rngd already installed).

Does anybody has another idea what I could try to fix this problem? Using /dev/urandom seems to be an insecure hack to me; so that's not an option (since CF10 server is production machine).

Thanks guys!

Community
  • 1
  • 1
Seybsen
  • 14,989
  • 4
  • 40
  • 73

1 Answers1

4

While making a cfhttp call to a coldfusion server the apache httpclient library tries to generate a secure random number. It is an operation which depends on the "entropy" of the system.

In case of linux systems (mainly the ones which are freshly installed) it is observed that this operation can be quite time consuming because the system "entropy" is apparently quite low. Hence, as a consequence cfhttp calls will be slow.

Source: http://blogs.coldfusion.com/post.cfm/optimizing-cfhttp-calls-on-linux-systems

Solution: Add “-Djava.security.egd=file:/dev/./urandom” to your jvm-setting.

In the Adobe Forums, you find another thread with your problem and the same solution and a following link with further informations about the random number generator: http://forums.adobe.com/thread/1063806

There is no need for not using /dev/urandom as it is a secure solution: https://security.stackexchange.com/a/3939

Community
  • 1
  • 1
da_didi
  • 832
  • 1
  • 7
  • 12
  • The OP has already stated in the question that they do not want to use the `/dev/urandom` option. They are looking for another solution. – Miguel-F Oct 08 '13 at 13:00
  • Security expert from Adobe wrote on her blog: "Note: #1 is the best solution and most secure. However for development phase and test environments (even for systems where you are ready to compromise on security), #4 solution is what I used and I recommend." where #1 is using something like rngd and #4 is using /dev/urandom. (http://www.shilpikhariwal.com/2012/04/random-number-generation-in-unix.html) – Seybsen Oct 08 '13 at 13:17
  • 3
    [Thomas Pornin](http://security.stackexchange.com/users/655/thomas-pornin) (the author of the answer da_didi links to) is a professional cryptographer - go look through his responses on http://security.stackexchange.com for his qualifications. If he's saying /dev/urandom is secure, then I'd ask anyone who disagrees to demonstrate why they believe him to be incorrect. – Peter Boughton Oct 08 '13 at 14:22
  • In the article that @Seybsen referenced above she even states that `/dev/urandom` is secure. From that page: _while /dev/urandom will always provide random bytes though they may become of a lesser quality once the initial buffer is outrun. However note that I am not implying that it is not secure at all._ – Miguel-F Oct 08 '13 at 14:41