I'm trying to obtain the supported cipher suite sent by the server during the the handshake protocol in an iOS app for HTTPS connections. So that, I could validate it against the recommended cipher suite in NIST Special Publication 800-52: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations Table 3-2.
I tried looking into the class NSURLProtectionSpace's methods and other related entities like SecTrust, SecCertificate functions, and ran out of luck. I was unable to find anything in Apple doc titled as "Certificate, Key, and Trust Services Reference" too.
I found something interesting though. A 'C' function SSLGetSupportedCiphers. This needs a SSLSessionRef object as parameter. And then I wasn't able obtain SSLSessionRef object from NSProtectionSpace object as this is the only parameter provide by the delegate
"connection:willSendRequestForAuthenticationChallenge:".
And of course how should I be able to, as session is not yet established. (But I'm guessing that this class might have information about supported cipher suites as it represent the server realm).
Question: How to get cipher suite supported by the server, sent during the handshake protocol at client end, before sending credential to server.
Note: I can only use standard Apple API. OpenSSL is not available as option. :-(
Related
My team is working on common criteria validation of one of the clients' products written in Delphi for Windows. The application uses winhttp api for making HTTP requests. We are using tls-cc-tools for checking whether the application passes all the TLSC EXT1.1 assurance tests. We have been able to restrict the cipher suites and enable TLS 1.2 application wide and right now test 1, test 4, test 5.1, test 5.2 and 5.3 are passing but the remaining tests are not passing. The tests can be found over here.
We have set the following options in winhttp:
df:={WINHTTP_DISABLE_AUTHENTICATION or }WINHTTP_DISABLE_COOKIES or WINHTTP_DISABLE_KEEP_ALIVE or WINHTTP_DISABLE_REDIRECTS;
WinHTTPSetOption(iconnection, WINHTTP_OPTION_DISABLE_FEATURE,#df,sizeof(df));
protocols := $00000800; //WINHTTP_FLAG_SECURETLS1_2;
WinHttpSetOption(iconnection, WINHTTP_OPTION_SECURE_PROTOCOLS, #protocols, sizeof(protocols));
WinHTTPSetOption(iconnection, WINHTTP_OPTION_SECURITY_FLAGS,
#flags, sizeof(flags));
Tests that are failing:
Test 3: The evaluator shall send a server certificate in the TLS connection that the does not match the server-selected ciphersuite (for example, send a ECDSA certificate while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA certificate while using one of the ECDSA ciphersuites.) The evaluator shall verify that the TOE disconnects after receiving the server’s Certificate handshake message.
Test 4: The evaluator shall configure the server to select the TLS_NULL_WITH_NULL_NULL ciphersuite and verify that the client denies the connection.
Test 5.5: Modify a byte in the Server Finished handshake message, and verify that the client sends a fatal alert upon receipt and does not send any application data.
Tests 5.6: Send a garbled message from the Server after the Server has issued the ChangeCipherSpec message and verify that the client denies the connection.
What should be done to ensure that the remaining tests pass?
Preface: I’m a certified Common Criteria Evaluator and a software developer. I’ve been dealing with the TLS and X.509 test cases for years.
Some of these tests are incredibly non-trivial to do correctly under all circumstances, such as FCS_TLSC_EXT.1 Test 3 above. It would be impossible to diagnose why you aren’t seeing the effect without knowing much more about your implementation and (most importantly) test setup.
However, test 4 is quite straightforward: set up your TLS server to respond only with the NULL cipher regardless of what the client asks. That can be done by a man-in-the-middle or by hacking the server. Either should force the client to disconnect well before it gets along much further.
Tests 5.5 and 5.6 are pure man-in-the-middle tests. If you are already using the TLS-cc-tools, then the basis for the test is already there.
Check my profile for ways to reach out to me directly to get more help with CC and TLS and X.509 conformance. These test cases aren’t industry standard implementations and are only for those who are seeking CC certification. It’s a niche market.
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'm trying to make a secure protocol between an iPhone app and an Arduino server. The goal is that the iPhone app makes a request to an Arduino server and the server only processes it if it has the proper credentials of one form or another. I'm not really sure how to approach this problem. Any suggestions are much appreciated!
Unfortunately there are no truly secure communication options available on Arduino. The basic problem is that SSL libraries have not been ported to this platform, partly owing to the fact that the 8-bit processors the platform is built around are not very powerful. Having said that there are some things you can do, but you'll have to do them yourself:
Basic access authentication is a very insecure method of controlling access to HTTP pages so it isn't recommended. Digest access authentication, on the other hand, employs one-way cryptographic encoding (hashing). It only requires MD5 library, which, is actually available for Arduino. What you'll need to do is modify the source code for the Web Server class to support digest access authentication: AFAIK it does not support it out of the box.
If this seems to difficult, you could implement something fairly basic (and not very secure, but better than nothing) yourself. It might look like this:
The first GET request comes in from a client
The server responds with "not authorized" response, embedding in the response a token which is related to (perhaps a hash of) the requesting IP address. You could make the original timeframe part of the hash as well, and give such tokens a limited lifetime.
If the next request from the same IP address includes a hash based on some secret code + the token sent, the next request is honored.
Now this will not protect you from IP address spoofing, and many other things I probably haven't thought of. However, it will give you a modicum of security (and a tiny bit of security through obscurity, if you believe in this sort of a thing). You could ask for (slightly) more elaborate schemes on superuser
You might be able to just use authenticated messages built on shared secrets. The message will contain [at minimum] a message type, message body, timestamp, and message digest. You create the digest by HMACing the other stuff with a shared secret. (Type HMAC Arduino into Google for libaries and code.) The message is sent over TCP or UDP (i prefer it). The Arduino computes digest of message, checks it, validates data, and then acts on message.
One thing I like to do is implement port-knocking or something at the network layer in front of the application server. This prevents unwanted traffic from reaching the custom (and possibly vulnerable) command server. This can be done stealthily (see Silent Knock) or obviously. The network protections can also be implemented by a dedicated device that does the heavily lifting and disqualifies much rogue traffic before it reaches the Arduino.
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.