I am using Fiddler 5.0 to capture https requests of mobile app. It works fine except one app. Below is logs of Fiddler.
21:31:59:7072 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
21:31:59:7072 !SecureClientPipeDirect failed: System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. < 处理证书时，出现了一个未知错误。 for pipe (CN=ci.migudm.cn, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com).
21:31:59:7412 !SecureClientPipeDirect failed: System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. < 处理证书时，出现了一个未知错误。 for pipe (CN=ci.migudm.cn, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com).
21:31:59:7862 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
Have you checked out the link provided by the logs? There's a bunch of very relevant information there that I think might help you get what you need:
Some web servers are unable to process Client Hello messages longer than 255 bytes, even though such messages are allowed by the protocol. Although most Client Hello messages are shorter than this limit, with the use of Server Name Indications (SNI), Elliptic Curve extensions, and the increase in the number of supported suites, the size can easily go over.
Browsers are thought not to be affected, but some other tools may be. In particular, OpenSSL 1.0.1+ is known to be affected. If you are using the s_client tool, try to reduce the size of the handshake by disabling some of the suites offered by OpenSSL (this can be done by specifying the desired suites using the -cipher switch).
OpenSSL Bug #2771: Openssl 1.0.1 times out when connecting to Outlook Exchange 2007; sign in with guest/guest.
F5 tracks this problem under bug #376483 and it is fixed in BIG-IP LTM 10.2.4 (see [SOL14758: SSL client connections may fail if the ClientHello message is greater than 255 bytes and uses TLS 1.1 or 1.2] (https://support.f5.com/kb/en-us/solutions/public/14000/700/sol14758.html) for more details).
Michael Tschannen says:
The issue is fixed according to F5 in 10.2.4, they are however not mentioned in any release notes (I have >just checked until 11.x)
To debug the issue on an F5, the log level of "SSH" needs to be at least "Informational".
Example:
Mar 22 09:44:21 local/tmm info tmm[4696]: 01260013:6: SSL Handshake failed for TCP from x.x.x.x:443 to x.x.x.x:49549
Source: https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
If you've been through all of this information, could you please provide the F5 version, OpenSSL version, and log information from OpenSSL?
Related
I have moved a PHP script to another server, and now fail to login to an IMAP (TLS) postbox:
TLS/SSL failure for mail.servername.de: SSL negotiation failed
It seems that the problem is caused by OpenSSL, because when I try to connect to the Mailserver from both servers, I get a connection in one case (the mailserver asking for input), but none in the other (the connection is closed, I am back to bash):
openssl s_client -crlf -connect mail.servername.de:993
The most obvious difference is here:
verify return:1
---
<snip>
-----END CERTIFICATE-----
subject=/CN=mail.servername.de
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 3398 bytes and written 483 bytes
Verification: OK
---
New, TLSv1.2, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
And on th other server (where no connection is made)
verify return:1
depth=0 CN = mail.servername.de
verify return:1
140410888582464:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2149:
---
<snip>
-----END CERTIFICATE-----
subject=CN = mail.servername.de
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
---
SSL handshake has read 3167 bytes and written 318 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Server public key is 2048 bit
On the mailserver dovecot is configured not to accept non-encrypted connections. But, I assume it already fails due to dh key too small, which seems to relate to cipher negotiation.
Now I simply fail to put the things together... Why does the SSL connection work from one server, but not from the other?
As I own the "remote end" myself, I was able to increase security. The solution is simple, and may be relevant for others as well ...
The dovecot version is 2.2.x, which is of some relevance for the DH parmaters (see Dovecot SSL configuration). In the configuration file /etc/dovecot/conf.d/10-ssl.conf you can simply add this line:
ssl_dh_parameters_length = 2048
And eventually, it may be necessary to add this here to the main configuration file /etc/dovecot/dovecot.conf at the end:
!include conf.d/*.conf
Finally, it is important not to reload, but to restart dovecot.
systemctl restart dovecot
And suddently, the weight, troubles, and frustration of several hours is gone. Great...
Further to the above, there's a change from dovecot 2.3.
ssl_dh_parameters_length is now not used, and ssl_dh must be used instead, to point to a file generated using
openssl dhparam 4096 > dh.pem
see https://doc.dovecot.org/configuration_manual/dovecot_ssl_configuration/ and scroll down to SSL Security Settings. That was the only change I had to make following the upgrade to get it to work properly again. I put the dh.pem file in /etc/dovecot, so my line in 10-ssh.conf is
ssl_dh=</etc/dovecot/dh.pem
TL;DR: your new host has a newer version of OpenSSL probably with higher security settings which prohibit connecting to the host for reasons explained below.
"dh key too small" comes from OpenSSL and because of too low security.
Things changed, and for example in newest Debian versions and with OpenSSL 1.1.1 (and I guess it is similar for newer versions), the security was enhanced.
The best and simplest explanation I have found is on Debian wiki at https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1
which says:
In Debian the defaults are set to more secure values by default. This
is done in the /etc/ssl/openssl.cnf config file. At the end of the
file there is:
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT#SECLEVEL=2
This can results in errors such as:
dh key too small
ee key too small
ca md too weak
Now the possible solutions in descending order of preference:
ask the remote end to generate better "DH" values ("Server Temp Key: DH, 1024 bits"); the best explanations are at https://weakdh.org/sysadmin.html; note specifically the "Administrators should use 2048-bit or stronger Diffie-Hellman groups with "safe" primes."
configure your end specifically for this connnection to not use the OS default and lower your settings; it should be enough to set ciphers to "DEFAULT#SECLEVEL=1" in the code that does the connection
(really, really, really not recommended) change the value of SECLEVEL from 2 to 1 in the global configuration file on your end. But this impacts all connections from your host not just this one so you are lowering the global security of your system just because of one low level of security from one remote node.
The Goal
I'm trying to make a call to a telephone number. I'd like to be able to make a call from the raspberry pi, and also make a call to my voip.ms phone number and be able to answer or auto-answer and play some generic .wav file.
My current understanding of things
This maybe should be titled "My current misunderstanding of things". I'm new to sip and pjsip, and I think I must be missing some part of the process I don't understand. I was under the impression that, if I register with voip.ms, when I make a call it would route to voip.ms and they would do a lookup on the number/address, and then respond with an address that I would then begin to communicate with.
What I've done so far
Compiled
I've compiled Pjsip on a Raspberry Pi 3B+ properly, for what I can tell. I can include pjsua2.hpp in my c++ applications. I've roughly followed this tutorial
Tested compilation with pjsua binary && demo.cpp
I'm running into identical problems running a modified pjsua2_demo.cpp and the binary included in the pjsip build. For the sake of simplicity, I'll ask about the binary located (for me) at <project-path>/pjproject-2.8/pjsip-apps/bin/pjsua-armv7l-unknown-linux-gnueabihf.
Successfully registered with voip.ms
I have an account and phone number with Voip.ms and can become registered with voip.ms by executing the following script:
call_and_auto_answer.sh
./pjsua2-cpp/pjproject-2.8/pjsip-apps/bin/pjsua-armv7l-unknown-linux-gnueabihf \
--play-file ~/CantinaBand60.wav \
--local-port=5060 \
--auto-answer 200 \
--auto-play \
--auto-loop \
--max-calls 5 \
--config-file ./sip.cfg
Where the config looks like:
sip.cfg
#
# Logging options:
#
--log-level 5
--app-log-level 4
#
# Account 0:
#
--id sip:<my-subaccount-username>#sip.voip.ms
--registrar sip:<server-location>.voip.ms
--reg-timeout 300
--realm *
--username <my-subaccount-username>
--password <my-subaccount-password>
--use-timer 1
#
# Network settings:
#
--local-port 5060
#
# Media settings:
#
--srtp-keying 0
--auto-play
--auto-loop
--play-file /home/pi/CantinaBand60.wav
--snd-auto-close 1
#using default --clock-rate 16000
#using default --quality 8
#using default --ec-tail 200
#using default --ilbc-mode 30
--rtp-port 4000
#
# User agent:
#
--auto-answer 200
--max-calls 5
#
# SIP extensions:
#
--use-timer 1
When I enter the cli, I see for my account list:
Account list:
[ 0] <sip:192.168.1.49:5060>: does not register
Online status: Online
[ 1] <sip:192.168.1.49:5060;transport=TCP>: does not register
Online status: Online
*[ 2] sip:<my-subaccount-username>#sip.voip.ms: 200/OK (expires=285)
Online status: Online
Buddy list:
-none-
Voip.ms shows I've registered on their website.
The problem
I'm trying to call my personal cell phone from my pi (I assume using the registered voip.ms phone number), and call my pi from my personal cell phone. While calling out I'm typically getting either 408 Request Timeout errors or 502 gethostbyname errors.
Different destinations, different errors
Depending on the destination for my call from the pi, I get one of two different errors most of the time
Timeout Error
I get an error that says,
18:19:19.757 pjsua_app.c ....Call 4 is DISCONNECTED [reason=408 (Request Timeout)]
18:19:19.757 pjsua_app_comm ....
[DISCONNCTD] To: <destination-sip-address>
where is any of the following:
sip:
sip:
sip:thetestcall#sip2sip.info
sip:thetestcall#iptel.org
sip:201#ideasip.com
and the phone numbers are formatted like: 3035551234, though I've tried prepending a 1 and a +1 just to check.
Lookup Error
I get an error that says,
19:09:45.435 sip_resolve.c ....Failed to resolve '<destination-sip-address>'. Err=70018 (gethostbyname() has returned error (PJ_ERESOLVE))
19:09:45.435 tsx0x18520dc ....Failed to send Request msg INVITE/cseq=10722 (tdta0x185012c)! err=70018 (gethostbyname() has returned error (PJ_ERESOLVE))
19:09:45.435 pjsua_app.c .......Call 4 is DISCONNECTED [reason=502 (gethostbyname() has returned error (PJ_ERESOLVE))]
19:09:45.435 pjsua_app_comm .......
[DISCONNCTD] To: sip:<destination-sip-address>
where is any of the following:
sip:
sip:
sip:abcd1234
Possible Successes
I'm getting what looks like a success while calling:
sip:**12340#ideasip.com
It confirms the call and has a bunch of messages, notable including:
19:16:17.550 pjsua_core.c ....TX 1300 bytes Request msg INVITE/cseq=13899 (tdta0x15c263c) to UDP 208.97.25.11:5060:
...
19:16:17.551 pjsua_app.c .......Call 4 state changed to CALLING
...
>>> 19:16:17.606 pjsua_core.c .RX 575 bytes Response msg 100/INVITE/cseq=13899 (rdata0x6d7008a4) from UDP 208.97.25.11:5060:
...
19:16:17.609 pjsua_core.c .RX 946 bytes Response msg 200/INVITE/cseq=13899 (rdata0x6d7008a4) from UDP 208.97.25.11:5060:
...
19:16:17.609 pjsua_app.c .....Call 4 state changed to CONNECTING
...
19:16:17.610 pjsua_app.c .....Call 4 state changed to CONFIRMED
...
19:16:17.676 pjsua_core.c .RX 594 bytes Response msg 100/INVITE/cseq=13900 (rdata0x6d7008a4) from UDP 208.97.25.11:5060:
...
19:16:17.678 conference.c ......Port 5 (sip:**12340#ideasip.com) transmitting to port 5 (sip:**12340#ideasip.com)
...
19:16:17.678 conference.c ......Port 1 (/home/pi/CantinaBand60.wav) transmitting to port 5 (sip:**12340#ideasip.com)
...
19:16:36.931 pjsua_app.c ......Call 4 is DISCONNECTED [reason=200 (Normal call clearing)]
Same Network
Additionally, if I set up a second pjsip client on the same network, I can call it from pi1 and answer the call on pi2.
Incoming calls
When I register with voip.ms, then try to call my voip.ms phone number from my personal cell phone, the call fails with a message on my iPhone that says, User Busy. This makes me think I'm messing something up with the registration, or that I'm missing some component, like a subscribe or link with that voip.ms account.
Final thoughts
I'm not sure what I'm missing here. I've read through a ton of the pjsip and pjsua docs, and I can't find anything I'm missing. Does anybody have insight into how to make a call to a phone number and allow for incoming calls? This has been quite a few days of solid work.
So I figured out the answer to my question. Here's the skinny:
Voip.ms registration
My registration with voip.ms wasn't configured properly. I was given credentials by a coworker, but upon further inspection of the sip endpoint, I found that the DiD number purchased for the account wasn't associated with the subaccount my coworker created for me. So, depending on the recipient's phone carrier, I was given different errors. Additionally, when I was testing inbound calls and receiving the error, User Busy, this was because the account I registered wasn't associated with the phone number.
To fix this, on voip.ms I associated the DiD number to my subaccount, and then went to my subaccount information and set the callerId number to be my DiD number, though I think you can override this value via pjsip.
Outbound sip calls
Secondly, to call a phone number, outbound calls should follow the following format:
sip:<phoneNumber>#<endpoint>
So for me, this looked very much like:
sip:5551234567#newyork.voip.ms
i have a Ubuntu 16.04.5 server with Vesta CP.
I checked the server on https://dnsflagday.net, and I got this report:
domain.cl. #123.456.78.90 (ns1.domain.cl.): dns=ok edns=ok edns1=ok edns#512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=timeout optlist=ok
domain.cl. #123.456.78.90 (ns2.domain.cl.): dns=ok edns=ok edns1=ok edns#512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=timeout optlist=ok
I do not know what edns512tcp = timeout means and I have not had much luck looking for a solution on internet.
Can someone help me? thanks
For that tool, any kind of "timeout" error is a problem, it means some server did not reply or the message (either query or reply) was eaten by some active element on the path, so it needs to be fixed.
edns512tcp is when the testing software does an EDNS query with a buffer of 512 bytes and over TCP.
If you go to https://ednscomp.isc.org/ednscomp/ for your domain you will have the full test results.
For that specific error it is:
EDNS - over TCP Response (edns#512tcp)
dig +vc +nocookie +norec +noad +edns +dnssec +bufsize=512 dnskey zone #server
expect: NOERROR
expect: OPT record with version set to 0
See RFC5966 and See RFC6891
So you can see which DNS query was done with dig, that you can reproduce it (+vc is an old flag name that is an alias for +tcp). The test expects to get a NOERROR code back and an OPT record. Your servers did not reply at all, so the test failed.
It seems that your servers did not reply to that at all, which is wrong. Maybe they do not reply to TCP queries at all which is even more wrong. In all cases you will need to contact the entity responsible for maintaining those servers and point it to the test results so that they start to fix the problem.
thanks for your help.
I read more about it and I could detect that port 53 was being blocked by the firewall, I added the rule to the firewall to allow TCP connections on port 53.
Everything it's fine now
Fiddler almost not work for me. Seems the problem only with https.
For example to open https google.com I need to wait around 40 seconds
Screenshots:
immediately after request
after ~40 seconds
Fiddler log:
18:02:46:3326 Fiddler Running...
18:02:46:3922 Windows 8+ AppContainer isolation feature detected.
18:03:09:5427 Assembly 'C:\Program Files (x86)\Fiddler2\CertMaker.dll' was not found. Using default Certificate Generator.
18:03:09:5467 /Fiddler.CertMaker> Using Fiddler.DefaultCertificateProvider+CertEnrollEngine for certificate generation; UseWildcards=False.
18:03:11:3745 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. githubcom /ssllabs/research/wiki/Long-Handshake-Intolerance
18:03:11:3855 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. githubcom /ssllabs/research/wiki/Long-Handshake-Intolerance
18:03:11:3895 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. githubcom /ssllabs/research/wiki/Long-Handshake-Intolerance
18:03:11:3915 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. githubcom /ssllabs/research/wiki/Long-Handshake-Intolerance
18:03:11:3945 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. githubcom /ssllabs/research/wiki/Long-Handshake-Intolerance
18:03:20:2192 [Fiddler] No HTTPS request was received from (chrome:10428) new client socket, port 6091.
18:03:20:3110 [Fiddler] No HTTP request was received from (chrome:10428) new client socket, port 6134.
18:03:20:3120 [Fiddler] No HTTP request was received from (chrome:10428) new client socket, port 6130.
18:03:28:8160 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. githubcom /ssllabs/research/wiki/Long-Handshake-Intolerance
18:03:30:2198 [Fiddler] No HTTPS request was received from (chrome:10428) new client socket, port 6095.
18:03:30:2198 [Fiddler] No HTTPS request was received from (chrome:10428) new client socket, port 6097.
18:03:30:2198 [Fiddler] No HTTPS request was received from (chrome:10428) new client socket, port 6099.
18:03:30:2198 [Fiddler] No HTTPS request was received from (chrome:10428) new client socket, port 6101.
18:03:50:2219 [Fiddler] No HTTPS request was received from (chrome:10428) new client socket, port 6163.
18:03:50:2219 [Fiddler] No HTTPS request was received from (chrome:10428) new client socket, port 6141.
18:03:50:2219 [Fiddler] No HTTPS request was received from (chrome:10428) new client socket, port 6167.
18:04:10:2230 [Fiddler] No HTTPS request was received from (chrome:10428) new client socket, port 6176.
18:04:10:2230 [Fiddler] No HTTPS request was received from (chrome:10428) new client socket, port 6179.
Many times in chrome I see: Waiting for proxy tunnel...and site shows This webpage is not available (ERR_TIMED_OUT)
In EDGE I even can't open http site for all sub requests I see blue up arrow which means fiddler trying to load it (after ~40 seconds I get loaded all that requests)
I tried to reset Internet Properties-> Advanced tab-> Restore advanced settings - it doesn't help me.
Also I tried to restarted my system, also I restarted fiddler after any changes I made.
Fiddler settings:
Certificates generated by CertEnroll engine. I tried to change it to MakeCert. Few times I reset All certificates, also manually removes certificates.
Browsers: Chrome/Firefox
Gateway info in fiddler: No upstream gateway proxy is configured.
Recently I made clear installation of Windows 10.
I do not have any Antivirus.
Windows 10 Pro x64
Fiddler v4.6.2.0
I need fiddler for my work. Please help me
UPDATED:
This is can be issue with Protocols. Currently in fiddler I have next protocols:
fiddler.network.https> HTTPS handshake to www.bing.com (for #4) failed. System.IO.IOException Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. < An existing connection was forcibly closed by the remote host
and
fiddler.network.https> HTTPS handshake to www.google.com.ua (for #23) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm
As I thought the issue was with protocols enabled in Internet Options in Windows and Fiddler protocols.
I ticked Use SSL 3.0 and use TSL 1.0 in Interent properties (all other should be unticked)
in Fiddler protocols I typed: ;ssl3;tls1.0
And after this changes everything works perfectly
Yes, Use SSL 3.0 and use TSL 1.0 in Internet properties for it to work. Previously I also did the same mistake but now working fine. I also checked on fiddler for the same.
We have a wildcard SSL certificate for our domains. If I setup the Secure Canvas URL, we get the dreaded empty response error. My understanding is that this is because Facebook has a problem with our SSL cert.
Is there any recommendations on how to figure out what is wrong with our SSL certificate?
I read this blog post: http://developers.facebook.com/blog/post/567/
I ran the test on the site they recommended, it looks pretty good to me. Could that Beast mode warning be causing this problem? Here are the results I get back:
Certificate Information
Common names *.mydomain.com
Alternative names *.mydomain.com mydomain.com
Prefix handling Not required for subdomains
Valid from Tue Jul 19 00:00:00 UTC 2011
Valid until Wed Jul 18 23:59:59 UTC 2012 (expires in 8 months and 18 days)
Key RSA / 2048 bits
Signature algorithm SHA1withRSA
Server Gated Cryptography Netscape Step-Up, Microsoft Server Gated Cryptography
Weak key (Debian) No
Issuer EssentialSSL CA
Next Issuer COMODO Certification Authority TRUSTED
Chain length (size) 2 (2581 bytes)
Chain issues None
Validation type Domain-validated (DV)
Revocation information CRL, OCSP
Revocation status Good (not revoked)
Trusted Yes
Protocols
TLS 1.2 No
TLS 1.1 No
TLS 1.0 Yes
SSL 3.0 Yes
SSL 2.0+ upgrade support Yes
SSL 2.0 Yes N
(*) N next to protocol version means the protocol has no cipher suites enabled
Cipher Suites (sorted by strength; server has no preference)
TLS_RSA_WITH_RC4_128_MD5 (0x4) 128
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits (p: 128, g: 1, Ys: 128) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 168
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) 168
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits (p: 128, g: 1, Ys: 128) 256
Miscellaneous
Test date Thu Nov 03 19:37:27 UTC 2011
Test duration 55.590 seconds
Server signature Apache
Server hostname dev.mydomain.com
Session resumption Yes
BEAST attack Vulnerable INSECURE (more info)
Secure Renegotiation Supported, with client-initiated renegotiation disabled
Insecure Renegotiation Not supported
Strict Transport Security No
TLS version tolerance 0x0304: 0x301; 0x0399: 0x301; 0x0499: fail
PCI compliant No
FIPS-ready No
Ephemeral DH 1024 bits (p: 128, g: 1, Ys: 128)
Are you missing the intermediate certificates? Check at http://www.sslshopper.com/ssl-checker.html to see if you have a full chain
Also good is the checker at https://www.ssllabs.com/
If the app is FBML Facebook is very strict about which certificates it will accept when connecting to your site to download the content - if your app uses iFrames it's mostly up to the user's browser settings and you'll get away with less strict checking
The quote from that blog post which seems to have tripped up most FBML apps is:
If you enable SSL for your FBML app, please make sure that your SSL certificate includes all intermediate certificates in the chain of trust as our SSL validation is strict. You can use third-party SSL analysis tools (e.g., https://www.ssllabs.com/index.html) to check your certificate status and fix any errors (and warnings). If your SSL certificate has problems, you may see "Empty response received" error when you load your FBML canvas app.