cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

user_2170816
New Contributor II

Hello everyone,

I m trying to make a https get request to a custom URL by using the https_client snip of WICED v3.5.2

By default, snip gets the ip of www.google.com and connect it over port 443. In my case, I have a custom URL like <hostname>:8080/<path>

I got the ip of my host, but I could not connect my address over port 8080 in no way.

When we got into the "wiced_https_get" function, we can easily see that a tcp connection with "wiced_tcp_connect( &socket, address, 443, 20000 );". I wrote 8080 which is my port instead of 443. Unfortunately, it did not work.

Right now, I m examining another snip which is httpbin_org, but I am stuck in it actually.

Is there anyone who tried something like that before?

Best regards...

Oguz.

0 Likes
1 Solution
VikramR_26
Employee

Nice to know you figured this.

No the fix will be present in the next SDK release. This is a temporary workaround .

the root_ca provided in the http_client needs to be changed for IIS servers.

Else we get ca_certificate error.

View solution in original post

0 Likes
24 Replies
VikramR_26
Employee

Could you try http_client instead of https_client, I know you want a secure http. Try to make sure if you can ping your server using http_client initially. let us know if that works?

0 Likes
AxLi_1746341
Honored Contributor

Hi,

I just test it with sdk-3.5.2, https_client looks ok to use other port number.

Though your test shows wiced_https_get function should allow specifying

the port number rather than hard-coded it.

BTW, Can you print out the return code of wiced_https_get()?

0 Likes
VikramR_26
Employee

I'm guessing if you print it as an int, you can see the result code.

0 Likes
AxLi_1746341
Honored Contributor

I just found https_get does not work for some URL (on port 443).

e.g.

Try running snip.https_get with slightly modification to connect careband.technoinnova.com

Then wiced_https_get() returns error.

I found the error is at the third time calling

result = ssl_handshake_client_async( &tls_context->context );

on sdk-3.1.2, the result is 19.

on sdk-3.5.2, the result is 1051.

Note, my modification in snip.https_get

1) replace "www.google.com" with "careband.technoinnova.com"

2) coment out wiced_tls_init_root_ca_certificates()

Can someone help?

Thanks.

0 Likes
AxLi_1746341
Honored Contributor

vik86

Seems many Microsoft Azure based servers have this issue:

I tried https_get to connect below sites, all fails with the same error code.

azure.microsoft.com

tryappservice.azure.com

0 Likes
AxLi_1746341
Honored Contributor

axel.lin wrote:

vik86

Seems many Microsoft Azure based servers have this issue:

I tried https_get to connect below sites, all fails with the same error code.

azure.microsoft.com

tryappservice.azure.com

Hi vik86, nsankar, Broadcom team,

Use https_client to test connecting azure.microsoft.com, then you will find it fails.

This issue happens on all platforms (at least happens on all the platforms I have) and happens on all SDK version.

Which means WICED devices cannot connect to Microsoft Azure based https servers.

The code in question is released in binary and we already got customers

report about this. We do need a bug fix for this for sdk-3.1.2.

Any chance to take a look at this issue?

Thanks,

Axel

0 Likes
AxLi_1746341
Honored Contributor

Use https_client to test connecting azure.microsoft.com, then you will find it fails.

This issue happens on all platforms (at least happens on all the platforms I have) and happens on all SDK version.

Which means WICED devices cannot connect to Microsoft Azure based https servers.

Hi list,

I think I figured out this problem.

All the connect failure web servers using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

which is not supported in current WICED SDK.

Do you have plan to support it? Many servers use TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 now.

Axel

VikramR_26
Employee

Yes i verified IIS server hosted websites are not responding to wiced_https_get, I realized if you add user-agent then we do not see error but response is null. So we will wrk on supporting this . Thanks to bring it our notice

Thnx

vik86

0 Likes
AxLi_1746341
Honored Contributor

vik86 wrote:

Yes i verified IIS server hosted websites are not responding to wiced_https_get, I realized if you add user-agent then we do not see error but response is null. So we will wrk on supporting this . Thanks to bring it our notice

Thnx

vik86

Hi vik86

I believe the "user-agent" you mentioned is a different issue.

Did you try connecting azure.microsoft.com using https_client snip code?

It's wiced_tcp_connect() error which is because of tls handshake error.

Can you double check by connecting azure.microsoft.com?

Thanks

0 Likes
AxLi_1746341
Honored Contributor

Did you try connecting azure.microsoft.com using https_client snip code?

It's wiced_tcp_connect() error which is because of tls handshake error.

Can you double check by connecting azure.microsoft.com?

Thanks

Hi vik86

Can you reproduce the issue by using https_client snip to connect azure.microsoft.com?

I'm still waiting for your feedback.

0 Likes
VikramR_26
Employee

Yes I do see the error Get failed: 7014. As you have mentioned earlier regarding the IIS servers its different. But if you use wiced_http_get with port changed to 883 i see different response. We are looking at this issue

0 Likes
AxLi_1746341
Honored Contributor

vik86 wrote:

Yes I do see the error Get failed: 7014. As you have mentioned earlier regarding the IIS servers its different. But if you use wiced_http_get with port changed to 883 i see different response. We are looking at this issue

Glad to see your progress.

I try to avoid mixing different issues.

So we have a couple issues now:

1) connect to azure.microsoft.com fails,

   My debug code shows it's ssl_handshake_client_async error.

   You can confirm this by printing result after below call.

   result = ssl_handshake_client_async( &tls_context->context );

   This is an important issue. As users have no way to work-aroud it.

   So need to figure out what is supported what is not.

2) You have verified IIS server hosted websites needs "user-agent".

   This is something people can work-aroud by adding "user-agent",

   but what is the suggested user-agent to put here?

3) You got Get failed: 7014, is that wiced_tcp_connect() error?

   Can you figure out the first place to get the error?

   Just to clarify if this is the same as issue 1) or a new issue.

4) You mentioned port changed to 883 then you see different response.

   I don't hit this issue, looks like a different issue from above list.

Well, I'm not clear which issue you are looking at now.

Thanks,

Axel

0 Likes
AxLi_1746341
Honored Contributor

axel.lin wrote:

vik86 wrote:

Yes I do see the error Get failed: 7014. As you have mentioned earlier regarding the IIS servers its different. But if you use wiced_http_get with port changed to 883 i see different response. We are looking at this issue

Glad to see your progress.

I try to avoid mixing different issues.

So we have a couple issues now:

1) connect to azure.microsoft.com fails,

   My debug code shows it's ssl_handshake_client_async error.

   You can confirm this by printing result after below call.

   result = ssl_handshake_client_async( &tls_context->context );

   This is an important issue. As users have no way to work-aroud it.

   So need to figure out what is supported what is not.

Hi vik86​,

Can you list the supported cipher suite by WICED SDK?

I know cipher_suites.c/cipher_suites.h files in SDK, but that file

does not list all supported cipher suite.

For example, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is not defined.

( Both USE_ECDHE_RSA_KEYSCHEME and USE_AES_128_GCM_CIPHER are not defined)

But I can connect to a server using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

This is probably a easy way to quickly identify if a https server can be connected

by WICED devices or not.

0 Likes
AxLi_1746341
Honored Contributor

axel.lin wrote:

Hi vik86,

Can you list the supported cipher suite by WICED SDK?

I figured out the supported cipher suites of WICED SDK by sniffer the https request.

Using WICED-3.1.2:

Cipher Suites (17 suites)

Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)

Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (0x00c4)

Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)

Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)

Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)

Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0x00be)

Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)

Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)

Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 (0x00c0)

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)

Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0x00ba)

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)

Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)

Cipher Suite: TLS_RSA_WITH_SEED_CBC_SHA (0x0096)

Using WICED-3.5.2:

Cipher Suites (12 suites)

Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)

Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)

Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)

Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)

Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)

0 Likes
AxLi_1746341
Honored Contributor

vik86 wrote:

Yes I do see the error Get failed: 7014. As you have mentioned earlier regarding the IIS servers its different. But if you use wiced_http_get with port changed to 883 i see different response. We are looking at this issue

Hi vik86​,

How is the progress of the issue about connecting to IIS server?

To clarify if we hit SNI issue, I download an old version of wget which does not

support SNI for testing. Below command works with the wget without SNI support:

wget https://careband.technoinnova.com/api/Test

However, WICED device still fails at ssl_handshake_client_async() as I reported

above. So now I think this failure is nothing to do with SNI, there must be

something wrong in the BESL library. I'm wondering if we hit the issue connecting

to IIS server as you mentioned, would like to know the progress of the fix.

0 Likes
AxLi_1746341
Honored Contributor

axel.lin wrote:

Use https_client to test connecting azure.microsoft.com, then you will find it fails.

This issue happens on all platforms (at least happens on all the platforms I have) and happens on all SDK version.

Which means WICED devices cannot connect to Microsoft Azure based https servers.

Hi list,

I think I figured out this problem.

All the connect failure web servers using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

which is not supported in current WICED SDK.

Do you have plan to support it? Many servers use TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 now.

Axel

After sniffer the TLS handshake of https client request, it looks like this actually is missing SNI issue.

Some (especially the servers host on Azure) servers disconnect immediately if client does not send SNI.

Can someone confirm and fix this ?

Thanks.

0 Likes
VikramR_26
Employee

We do support the below ciphers:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 and also this

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Will work on providing a list of supported ciphers. But yes we do support the above two mentioned.

We are presently looking at the issue in detail regarding the error 7014

0 Likes
AxLi_1746341
Honored Contributor

vik86 wrote:

We do support the below ciphers:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 and also this

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Will work on providing a list of supported ciphers. But yes we do support the above two mentioned.

We are presently looking at the issue in detail regarding the error 7014

I'm pretty sure SDK-3.5.2 does not support above ciphers you mentioned.

You had better document which SDK version includes which ciphers.

(See my previous post, SDK-3.1.2 and SDK-3.5.2 includes different set of ciphers.)

It's better for both of yourself and users to identify issues.

0 Likes
VikramR_26
Employee

In SDK 3.5.2 look for dtls_cipher_suites.c and you can look for TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and also TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

in SDK 3.1.2 we did not have this, but in SDK 3.5.2 these are supported.

0 Likes
AxLi_1746341
Honored Contributor

vik86 wrote:

In SDK 3.5.2 look for dtls_cipher_suites.c and you can look for TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and also TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

We are talking htts_client issue here, which is using TCP rather than UDP.

So I have no idea why you mentioned dtls_cipher_suites.c here.

In additional, if you look at the code you will see the

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

are guarded by the ifdefs.

Below are never defined:

USE_DTLS_ECDHE_RSA_KEYSCHEME / USE_DTLS_AES_128_GCM_CIPHER / USE_DTLS_SHA384_MAC

Which means they are not supported!

0 Likes
AxLi_1746341
Honored Contributor

Hi vik86​,

I'm still waiting for your feedback as there is nothing I can do for this issue.

Note, To avoid SNI issue, careband.technoinnova.com already switch to use

IP based SSL instead of SNI based SSL. But WICED device still connect fails.

You can try connect to below server to verify if your fix works or not.

https://careband.technoinnova.com/api/Test

0 Likes
VikramR_26
Employee

We realized the TLS version is causing the failure for IIS hosted servers.


Changing the following line in

WICED-Trunk\Wiced-SDK\WICED\security\BESL\host\WICED\tls_cipher_suites.c

from

tls_version_num_t tls_maximum_version = TLS1_2; 

to

tls_version_num_t tls_maximum_version = TLS1_1; 

Is a temporary workaround to get around this.

Also changing the CA certificate in accordance to Microsoft is required.

0 Likes
AxLi_1746341
Honored Contributor

I know the workaround to downgrade to use TLS1_1.

I applied it for one of our customer 2 months ago.

(The downside is I need to maintain a special version of firmware for the customer.)

However, is this fixed in SDK-3.7.0?

BTW, what do you mean by changing the CA certificate in accordance to Microsoft is required?

0 Likes
VikramR_26
Employee

Nice to know you figured this.

No the fix will be present in the next SDK release. This is a temporary workaround .

the root_ca provided in the http_client needs to be changed for IIS servers.

Else we get ca_certificate error.

View solution in original post

0 Likes