web services - SOAP Request fails randomly on one Server but works on an other on iOS7 -


i have iphone app gets data soap requests. soap calls done sudzc.com library.

i have make soap request 2 servers.

  • server a: own server, retrieve informations, soap response written myself
  • server b: third party server gives me necessary informations

ios 6 app working 100% correct.

ios 7

  • server a: working perfectly
  • server b: soap requests randomly fails. getting following error message sometimes:

    < soap-env:envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"> < soap-env:header/> < soap-env:body> < soap-env:fault> < faultcode>soap-env:server < faultstring xml:lang="en">could not access envelope: unable create envelope given source: ; nested exception com.sun.xml.internal.messaging.saaj.soapexceptionimpl: unable create envelope given source: : unable create envelope given source: : org.xml.sax.saxparseexception: markup in document preceding root element must well-formed.: markup in document preceding root element must well-formed. < /faultstring> < detail/> < /soap-env:fault> < /soap-env:body> < /soap-env:envelope>

anyone has idea, why happens on ios7 , how rid of it?

update: may related fact, 1 server running on https , other runs on http?

i have written support request ios team. here replied... in fact has htpps... in case runs same error, here might reason why:


i'm responding question why soap requests failing on ios 7, when targeting 1 of 2 servers. wrote:

may related fact, 1 server running on https , other runs on http?

it turns out theory correct. problem here ios 7 includes recommended countermeasure beast attack.

http://en.wikipedia.org/wiki/transport_layer_security#beast_attack

http://www.educatedguesswork.org/2011/11/rizzoduong_beast_countermeasur.html

https://www.imperialviolet.org/2012/01/15/beastfollowup.html

ios applies countermeasure when talks tls 1.0 or earlier server (tls 1.1 , later include own fix attack) negotiates use block cypher (stream cyphers not vulnerable attack).

looking @ packet trace of test app sent me, can see opens tls 1.2 connection www.xxxx.xy:443. server downgrades connection tls 1.0 , negotiates use aes-128 block cypher (ssl_rsa_with_aes_128_cbc_sha). after can see unmistakable signs of countermeasure kicking in.

i confirmed analysis running test app on simulator (which accurately reproduces problem) , then, using debugger, setting internal state of secure transport (the subsystem implements tls on ios) disable countermeasure entirely. on doing found first tab in app works fine.

a well-known side effect of countermeasure causes problem poorly written https servers. that's because breaks http request (the 1 running on tls connection) chunks, , server must coded correctly receive these chunks , join them single http request. servers don't properly, results in variety of interesting failures.

the best way solve problem fix server. server should able cope receiving http message in chunks, detecting http message boundaries in manner prescribed rfc 2616.

http://www.ietf.org/rfc/rfc2616.txt

if fix hard implement in short term, can work around problem upgrading server support tls 1.2. idea anyway.

another workaround, 1 that's less idea, tweak server configuration negotiate use of stream cypher.

if don't control server, encourage lobby server operators server-side fix problem. ios 7 not client that's implementing workaround; you'll find in recent versions of both chrome, firefox , on.

if server-side fix not possible, options on client side less ideal:

o replace https http. not thing, , requires server support http. also, http comes own array of un-fun problems (various middleboxes, run cellular carriers, monkey http messages).

o @ lowest level, can disable countermeasure given secure transport context way of ksslsessionoptionsendonebyterecord flag (see ). flag not directly available higher-level software, although possible use @ cfsocketstream layer (because api gives way @ secure transport context it's using).

important: high-level apis, nsurlsession , nsurlconnection, don't give access secure transport context, nor provide control on aspect of tls. thus, there's no way disable countermeasure , continue working nice, high-level apis.

o implement own http layer on top of our tls infrastructure (ideally cfsocketstream). alas, whole world of pain: http lot more complex might think.

i'm sorry don't have better news.


Comments

Popular posts from this blog

java.util.scanner - How to read and add only numbers to array from a text file -

rewrite - Trouble with Wordpress multiple custom querystrings -