when I try to query a test, freely available, environment, the command below will return the required answer...
lnSuccess = loRest.Connect("https://api.test.....com", 443, 1, 1)
But how to ask the production environment where certificate verification is required?
Many thanks
J.B.
You would use the Chilkat Socket object to connect, then use Rest.UseConnection. See https://www.example-code.com/foxpro/rest_useSocketObject.asp
The reason Chilkat did it this way is to avoid needing to add all of the TLS connection related properties to Rest. Instead, you can use the full flexibility of the Socket object to make the connection, then just tell Rest to use the already-established connection.
To make the TLS connection with certificate verification, call Socket.SetSslClientCert, SetSslClientCertPem, or SetSslClientCertPfx (see https://www.example-code.com/foxpro/socket_tlsClientCert.asp) prior to connecting.
Related
Background
I have a third-party framework that does some network requests to the URL which I provide to it.
The format of requests is:
https://10.0.2.2:8000/api/....
Since the schema is https I constantly receive the error message from the third party lib:
The certificate for this server is invalid. You might be connecting to a server that is pretending to be “10.0.2.2” which could put your confidential information at risk.
The server is a Django application started with
python3 manage.py runserver_plus 10.0.2.2:8000 --cert-file _my_cert.crt
I've tried a lot of ways to generate and install the self-signed certificate to the simulator and run the server, however, none of them have helped to avoid the error in the third party lib.
The Question
So I'm wondering if this makes sense at all.
Is it possible to generate and install self-signed certificate into iOS simulator which will avoid solving the challenging as is described here:
https://developer.apple.com/documentation/foundation/url_loading_system/handling_an_authentication_challenge/performing_manual_server_trust_authentication?language=objc
Please, provide proofs for any kind of answer whether yes or no.
You can get free SSL Certificate from https://letsencrypt.org
Just try it once.
For developing/testing purposes, I think the easiest way to go is to use a tunneling service like serveo. Execute the next command on the application server and this will keep the connection open:
ssh -o ServerAliveInterval=60 -R 80:localhost:8000 serveo.net
You can check for more config options on serveo. For example, you could set up a custom domain name like custom_domain.serveo.net.
You also have alternatives like ngrok.
It seems there are a couple choices within Xcode/iOS to communicate with my server, using simple HTTP requests or creating a full blown socket system. What vulnerabilities does each have? My main concern is that I can't allow someone to replicate a call that's not from my app, like you could spoof an AJAX call by examining a webpage's Javascript and getting the address for the call. Obv it wouldn't be so simple with a phone app, but I don't know what's possible for hackers.
Use HTTPS.
Override the TLS chain validation to fail if the public key doesn't match the one stored in your app.
In Apple's TLS validation doc below, start with "Listing 3 Overriding the trust object used by an NSURLConnection object", then add code so that if certificate evaluation succeeds, you check the key inside the challenge's protection space against a known-valid key (or keys) before allowing the connection to proceed.
I'm completely new to SSL and these ciphering stuff but I need to make communicate client and server Delphi XE6 apps running on mobile devices. The TCP communication has to be safely ciphered.
To start, I simply wrote the Delphi/Indy TIdTCPServer/TIdTCPClient based Win32 client and server exchanging strings. (Issued from the indy10clieservr demos found on SourceForge: svn://svn.code.sf.net/p/indy10clieservr/code/1_sample Simple String Exchange)
I tried to modify them to cipher the communication by adding a TIdServerIOHandlerSSLOpenSSL component on the Server, and a TIdSSLIOHandlerSocketOpenSSL on the Client, attaching them respectively to the TIdTCPServer and TIdTCPClient.
I set their following properties on both sides:
- SSLOptions.Method = sslvSSSv23
- SSLOptions.Mode = sslmServer / sslmClient (respectively)
- SSLOptions.VerifyDepth = 2
And I added an OnGetPassword Event handler setting the Password parameter to 'password' on both sides too.
(What is the role of this password ? Is it critical for the privacy of the communication ? What if it is found by analysing/reverse enginering the binary file ?)
Finaly, in the server's OnConnect event handler I set the TIdSSLIOHandlerSocketBase(AContext.Connection.IOHandler).PassThrough property to false.
But what about the 3 SSLOptions certificate properties ??
- CertFile
- KeyFile
- RootCertFile
How to generate and deploy them on my target devices to make run my SSL layer on the client and server ?
Moreover, is there something special to do or to take into acount if I intend to deploy later my server and/or clients on IOS or Android mobile device.
I'm aware that I have few knowledge on this SSL topic. Sorry if I ask something trivial. Any basic documentation explaining all of this tricky stuff to a newbie would be greatly appreciated.
As I told you in my answer to your same question on the Embarcadero forums, certificates are optional. They are used to allow peers to validate each other's identities, not for encryption. Certificates help avoid man-in-the-middle attacks, by allowing a client to verify it is connected to the correct server it is expecting to be connected to, and vice versa. It is not common for a client to have a certificate, except maybe when making a proprietary system where only authorized clients are allowed to connect. But it is pretty common for servers to have certificates, at least. Certificates can be password-protected, so if you do use them, you have to provide the correct password for the certificate(s) that you are actually using. A certificate's password can't be retrieved from the certificate itself, but if an attacker gains access to your certificate files then you have bigger issues to deal with.
As for SSLv23, it is a wildcard that allows dynamic version negotiation in cases where
client and server support different SSL/TLS versions. SSLv23 allows them
to figure out and use the highest version common to both parties. If a server
needs to support a wide range of clients, it makes sense to use SSLv23 on
the server side. Not so much on the client side. Since you control both
client and server, you should use use a specific version instead, preferrably
TLSv1 or higher.
I want to confirm the identity of the server my client is communicating with over a HTTPS connection.
There would appear to be two options, however I've not been able to find anything describing what the advantages/disadvantages of one method over the over is. Which of these is more secure and why?
1) Create a self-signed certificate which is used by the server and added to the application bundle and set as an anchor certificate using SecTrustSetAnchorCertificates()
2) Create an NSURLProtectionSpace and set its realm, host, port, and protocol, then compare it with the NSURLProtectionSpace in the NSURLAuthenticationChallenge passed into willSendRequestForAuthenticationChallenge:.
Does it make much difference which of these authentication mechanisms is used to verify the server?
TIA
Technical Note 2232: HTTPS Server Trust Evaluation describes best practices for evaluating trust over SSL/TLS.
It's not clear from the question wether you're interested in only self signed certificates or evaluating trust in general. In general, avoid using self signed certificates in production environments. If you must use a self signed server certificate, you should be rigorous in verifying that the credentials are what you expect. At the very least you should check the public key the server provides against a known value (SSL public key pinning). An example to get you started is here.
I am using the indy components to implement emails in a delphi application. I am specifically using the TidSMTP component. I need to effectively support all major email servers. I use Mozilla Thunderbird as my email client and am comparing the smtp properties with those in the TidSMTP component. I have attempted to find documentation that describes the relationship between the TidSMTP properties, but have not been able to figure it out.
Can someone explain how these compare and what they do:
In Thunderbird:Connection Security: (None, STARTTLS, SSL/TLS).
In TidSMTP.UseTLS (utNoTLSSupport, utUseImplicitTLS, utUseRequireTLS, utUseExplicitTLS)
In Thunderbird:Authentication method: (No Authentication, Normal Password, Encrypted Password, Kerberos/GSSAPI, NTLM)
In TidSMTP (username, password, with useAuthentication method)
I also see other TidSMTP properties: UseEhlo, UseVerp, UseNagle. Do I need to be using these? What do they do?
When using STARTTLS, the server's listening port is initially unencrypted upon connecting. When a client connects, it can send an optional STARTTLS command to the server, if the server supports it, to dynamically perform the SSL/TLS handshake at that time. This allows legacy non-SSL/TLS clients to continue connecting to that same port, while allowing newer SSL/TLS-enabled clients to use SSL/TLS if available on the server. This corresponds to UseTLS=utUseExplicitTLS in Indy. You need to set UseEHLO to True in order to use UseTLS=utUseExplicitTLS, as the EHLO command is how TIdSMTP discovers whether the server supports the STARTTLS command or not.
When using SSL/TLS instead of STARTTLS, the server's listening port is always using encryption and the client must initiate the SSL/TLS handshake immediately upon connecting before any other data can be exchanged. This corresponds to UseTLS=utUseImplicitTLS in Indy. There is no STARTTLS command used.
For authentication, TIdSMTP has two options - the old (and unsecure) AUTH LOGIN command that is defined by the original SMTP spec, and SMTP extensions for SASL-based hashing/encryption algorithms (Kerberos, GSSAPI, NTLM, etc are implemented as SASL algorithms).
To use SASL, set TIdSMTP.AuthType to satSASL and then fill in the TIdSMTP.SASLMechanisms collection to point at separate TIdSASL-derived components for the algorithms you want to support in your app. Indy has native SASL components for DIGEST-MD5, CRAM-MD5, CRAM-SHA1, NTLM (experimental), ANONYMOUS, EXTERNAL, OTP, PLAIN, SKEY, and LOGIN (SASL wrapper for AUTH LOGIN). If you need another algorithm (Kerberos or GSSAPI, for instance), you will have to write your own TIdSASL-derived component. For algorithms that use Username/Password, the values must be assigned to a separate TIdUserPassProvider component that is then assigned to the SASL components (the TIdSMTP.UserName and TIdSMTP.Password properties are not used with SASL). The more SASL algorithms you support, the wider the number of servers you will be able to support.
For servers that still support AUTH LOGIN, it can be used either by setting TIdSMTP.AuthType to satDefault (and optionally setting TIdSMTP.ValidateAuthLoginCapability to False if the server supports AUTH LOGIN but does not report it in response to the EHLO command) and then filling in the TIdSMTP.UserName and TIdSMTP.Password properties, or by including the TIdSASLLogin component in the TIdSMTP.SASLMechanisms collection.
UseVerp and UseNagle have nothing to do with security. VERP is an SMTP extension for detecting bouncing emails due to undeliverable errors. Nagle is a networking algorithm for optimizing network data packets.