In iOS 9 with ATS (App Transport Security) enabled without any exceptions I could not connect to a server via http. Which I would expect.
IE:
http://192.168.22.33
However with no changes in iOS 10 I can make that connection.
Looking here I don't see any updates on why this might be:
https://developer.apple.com/library/content/releasenotes/General/WhatsNewIniOS/Articles/iOS10.html
Any ideas? I want to make sure I am still getting ATS protection.
Availability of ATS for Remote and Local Connections
App Transport Security (ATS) applies only to connections made to public host names. The system does not provide ATS protection to connections made to:
Internet protocol (IP) addresses
Unqualified host names
Local hosts employing the .local top-level domain (TLD)
To connect to an unqualified host name or to a .local domain, you must set the value of the NSAllowsLocalNetworking key to YES.
Note: Although ATS is unenforced for connection to local hosts, Apple strongly recommends using Transport Layer Security (TLS) for any local connection, along with the use of a self-signed certificate to validate the local IP address. Apple Doc.
The system does not provide ATS protection to connections that with Internet protocol (IP) addresses. So We can connect to server IP without any NSAllowsLocalNetworking in the plist file.
Related
I'm using Angular 14 and the ngx-mqtt front-end lib.
Here's my connection string which works fine:
getEmqxCloudConnection(): IMqttServiceOptions {
return {
hostname: 'xx.xx.xx.182',
port: 8083,
path: '/mqtt',
clean: true, // retain
connectTimeout: 4000,
reconnectPeriod: 4000,
clientId: 'HarBrowserTest1',
username: 'myUser',
password: 'myPass',
protocol: 'ws',
connectOnCreate: false,
};
}
As per their Broker dashboard the available ports are:
Ports: 1883(mqtt), 8883(mqtts), 8083(ws), 8084(wss)
I have already imported our SSL Certificate into the EMQX Dashboard, yet when I change my conn string to port: 8084 and protocol: 'wss' - IT DOESN'T CONNECT !
They have some screenshots here showing their Client Tool, but for reason every one shows port=1883 (a mistake maybe). https://docs.emqx.com/en/cloud/latest/connect_to_deployments/mqttx.html#connection-configuration
In my Chrome browser network tab, here's what I see for the std insecure ws - A successful ws conn to the Mqtt Broker.
Here is the certificate UI which I used to imported the PEM-Encoded cert body and key:
This will most likely be down to the certificate you have used for the broker.
First unless you have created the certificate just right (using the correct SAN entries) that include the IP address as the principal for the certificate, then the connection will get rejected because the certificate doesn't match the hostname/IP address the broker is using to connect.
Second, if it is a self signed certificate then the browser will just reject it, unless you have manually imported the CA (or if it really is self signed the cert it's self) into the browsers trust store and marked it as trusted. The browser will NOT show you a warning and ask to accept for a WebSocket connection like it does with a webpage, it will just fail with an error in the console and nothing else.
P.S. - You should not hard code the client id in web apps, this is because client ids must be unique across ALL clients, so hardcoding it means that everybody that visits the page will use the same client id and each new connection will kick off the last one (and probably end up in a reconnect fight)
If you check the logs of EMQX, maybe you can get more helpful information.
The following are possible reasons for common TLS connection failures.
First of all, as mentioned in the previous answer, your certificate may have a domain name or IP address set as CN or SAN when it is issued, but the address you specified when connecting does not match the values of the CN and SAN fields.
In this case, the TLS client will think that the server you are connecting to may not be what you really expect, so it will refuse the connection.
We have three ways to solve it:
Turn off the verification of the peer certificate, if your client has this option. However, we do not recommend this as it increases the security risk.
Reissue a certificate that matches your server address
Set the SNI field (full name Server Name Indication) when the client connects, so that TLS will check whether the SNI matches the CN and SAN fields of the certificate, instead of your actual connection address.
The second possible reason is that your certificate path is incomplete, such as the lack of intermediate certificates, or the client does not specify a trusted root certificate, its keyword in the EMQX log is unknown_ca.
For more TLS error reasons, you can refer to SSL Connection Error.
In a browser environment, you should use a server certificate issued by a CA Signed than a self-signed certificate.
Self-Signed SSL Vs Trusted CA Signed SSL Certificateļ¼ see the https://cheapsslsecurity.com/blog/self-signed-ssl-versus-trusted-ca-signed-ssl-certificate/
I created a simple .NET Core Console application on C# which uses TcpListener to accept connections on a specific port and return an answer.
I bought an AWS Lightsail instance and deploy my server application manually via RDP. The instance has a static IP-address and a domain name like ec2-<IP>.eu-central-1.compute.amazonaws.com (as I discovered via reverse DNS lookup). The client is an iOS application and it needs a secure TCP connection to transfer data to server and vice versa. iOS app is not working with my self-signed certificate - it needs to use certificate from trusted CA, so the question is: where I can get the trusted SSL-certificate for Amazon Lightsail instance mentioned above?
I created a package to help with sockets and iOS using Obj-C. Also included is a very good resource for creating a certificate that will work. You will actually probably need to create a certificate authority, and intermediate certificate authority, and server/client certificates, check out the link:
https://github.com/eamonwhiter73/IOSObjCWebSockets/tree/master
Is it mandatory by Apple to use the domain name of my application server, or can I just use the IP address? Is my app going to be rejected by Apple, if I don't use a domain?
ATS protection does not apply for resources loaded via IP address, assuming you are loading over HTTP. Attempting HTTPS will throw an exception (As HTTPS by design requires a domain and an accompanying certificate)
I am trying to add my application on app store but it returns this error
that my application not support ipv6 and people told me that i should create ipv6 network to test my app.
now i have data on server but server which have this data doesn't support IPV6 only support IPV4 should it support IPV6 or it's ok to use IPV6 to get data from server that doesn't support IPV6
Your server can receive requests over IPv6 in two ways:
1) Your server support IPv6 and has IPv6 address (Also most hosting support this feature).
2) Some device (hardware or Linux router) in front of the server should support both IPv6 and IPv4. It will receive requests over IPv6 and transmit them to your server over IPv4.
You may try to answer Appstore, that your hosting provider on server side do not support IPv6. For my case It worked.
This is a sensitive topic and many people have wrong knowledge about it.
Your app MUST support IPv6-only networks. But your server MAY NOT support IPv6: it is up to you, to decide to support it or not.
In-depth explanation: Apple expects your client application to work correctly when connected to an IPv6-only network, but that IPv6-only network MUST help your application by offering a DNS resolver that is DNS64 compliant (RFC 6147) and also offering a NAT64 (RFC 6146) IPv6-to-IPv4 translation gateway. This means your client application makes a DNS request to www.myipv4onlyserver.com and the resolver replies with a fake IPv6 address routed to a NAT64 gateway. Thus, your client application talks with IPv6 to this gateway and this gateway translates the data channel to your IPv4 server, like a transparent proxy.
To be compliant with Apple expectations, use high-level network libraries and address-agnostic APIs, such as getaddrinfo() and getnameinfo(). Use hostnames or FQDN, not IP adresses.
See this Apple forum article and this Apple networking guide for further explanations.
I have an iOS client app which connects to a server using HTTPS.
I've added code in the client to verify the identify of the server.
How can a tester testing this feature test that it is now secure, how can they for example create a MITM situation and check that the client rejects connects etc.?
I've tried googling for how to do this but haven't had much luck.
Can it be done using tools like Charles and proxies etc. or is messing around with a wireless router and having detailed knowledge necessary?
This might be over simplification for your solution, but concepts might help.
A web browsers extracts the name of hosts from embedded certificate and do a comparison of host name that we're trying to connect with. If validation fails, we usually see a security warning. For ex: we can connect with facebook by either typing https://www.facebook.com or by typing https://173.252.100.16/. When we choose second option, we get a security warning.
Your program must be using SSL client socket to connect with HTTPS server. The socket must be having capability to extract the hostname from the embedded certificate. Once you get that, compare that with valid HOST NAME that your program is trying to connect with. If it matches, let request proceed, If not, abandon that session.
To re-create MITM, your web server can use a self signed certificate that can be issue to whatever host name you want, but the IP of server could be 127.0.0.1 (for example). Since there is a mismatch between the host name and actual IP, we can probably simulate the MITM situation.
I'm assuming that digital certificate can't be forged in this case.