Caused by: javax.net.ssl.SSLProtocolException: SSL handshake terminated: ssl=0x76a8eb8a00: Failure in SSL library, usually a protocol error error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE (external/boringssl/src/ssl/s3_pkt.c:641 0x76a8e2b0a0:0x00000001) error:1000009a:SSL routines:OPENSSL_internal:HANDSHAKE_FAILURE_ON_CLIENT_HELLO (external/boringssl/src/ssl/s3_clnt.c:800 0x76d2e2c253:0x00000000)
at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:364)
SSLV3 - wrapper string, actualy sslv3 not use
My web server is (include version):
nginx version: nginx/1.14.1
built with OpenSSL 1.1.0f 25 May 2017 (running with OpenSSL 1.1.0l 10 Sep 2019)
TLS SNI support enabled
The operating system my web server runs on is (include version):Debian GNU/Linux 9.13 (stretch)
Previously, the RSA private key was generated. And everything worked. Now a private key has been generated as EC and application (with okhttp3https://square.github.io/okhttp12or direct use ssl) on Android 7.0 - cannot connect (application using android webclient backend is working).
The only way to fix this is by NOT using an EC certificate. Right now you can work around by switching to P-256, but as the future E1 intermediate is P-384, that's not a long term solution.
요약
Android Side 에서 SSL Connection Handshake 가 날 때에 인증에 EC 인증서를 사용하면 안된다는 이야기이다. 즉, 안드로이 측면에서 고치려면 RSA 를 강제하고 인증서를 넘기면 된다.
Swift gives us an alternative toif letcalledguard let, which also unwraps optionals if they contain a value, but works slightly differently:guardlet is designed to exit the current function, loop, or condition if the check fails, so any values you unwrap using it will stay around after the check.
To demonstrate the difference, here’s a function that returns the meaning of life as an optional integer:
func getMeaningOfLife() -> Int? {
42
}
And here’s that function being used inside another function, calledprintMeaningOfLife():
func printMeaningOfLife() {
if let name = getMeaningOfLife() {
print(name)
}
}
That usesif let, so that the result ofgetMeaningOfLife()will only be printed if it returned an integer rather than nil.
If we had written that usingguardlet, it would look like this:
func printMeaningOfLife() {
guard let name = getMeaningOfLife() else {
return
}
print(name)
}
Yes, that’s a little longer, but two important things have changed:
It lets us focus on the “happy path” – the behavior of our function when everything has gone to plan, which is to print the meaning of life.
guardrequires that we exit the current scope when it’s used, which in this case means we must return from the function if it fails. This is not optional: Swift won’t compile our code without thereturn.
It’s common to seeguardused one or more times at the start of methods, because it’s used to verify some conditions are correct up front. This makes our code easier to read than if we tried to check a condition then run some code, then check another condition and run some different code.
So, useif letif you just want to unwrap some optionals, but preferguard letif you’re specifically checking that conditions are correct before continuing.
Trusty is a secure Operating System (OS) that provides a Trusted Execution Environment (TEE) for Android. The Trusty OS runs on the same processor as the Android OS, but Trusty is isolated from the rest of the system by both hardware and software. Trusty and Android run parallel to each other. Trusty has access to the full power of a device’s main processor and memory but is completely isolated. Trusty's isolation protects it from malicious apps installed by the user and potential vulnerabilities that may be discovered in Android.
Trusty is compatible with ARM and Intel processors. On ARM systems, Trusty uses ARM’s Trustzone™ to virtualize the main processor and create a secure trusted execution environment. Similar support is also available on Intel x86 platforms using Intel’s Virtualization Technology.
A Linux kernel driver to transfer data between the secure environment and Android
An Androiduserspace libraryto communicate with trusted applications (that is, secure tasks/services) via the kernel driver
Note:Trusty and the Trusty API are subject to change. For information about the Trusty API, see theAPI Reference.
Why Trusty?
Other TEE operating systems are traditionally supplied as binary blobs by third-party vendors or developed internally. Developing internal TEE systems or licensing a TEE from a third-party can be costly to System-on-Chip (SoC) vendors and OEMs. The monetary cost combined with unreliable third-party systems creates an unstable ecosystem for Android. Trusty is being provided to its partners as a reliable and free open source alternative for their Trusted Execution Environment. Trusty offers a level of transparency that is just not possible with closed source systems.
Android supports various TEE implementations so you are not restricted to using Trusty. Each TEE OS has its own unique way of deploying trusted applications. This fragmentation can be a problem for trusted application developers trying to ensure their apps work on every Android device. Using Trusty as a standard helps application developers to easily create and deploy applications without accounting for the fragmentation of multiple TEE systems. Trusty TEE provides developers and partners with transparency, collaboration, inspectability of code, and ease of debugging. Trusted application developers can converge around common tools and APIs to reduce the risk of introducing security vulnerabilities. These developers will have the confidence that they can develop an application and have it reused across multiple devices without further development.
Applications and services
A Trusty application is defined as a collection of binary files (executables and resource files), a binary manifest, and a cryptographic signature. At runtime, Trusty applications run as isolated processes in unprivileged mode under the Trusty kernel. Each process runs in its own virtual memory sandbox utilizing the memory management unit capabilities of the TEE processor. The build of the hardware changes the exact process that Trusty follows, but for example, the kernel schedules these processes using a priority-based, round-robin scheduler driven by a secure timer tick. All Trusty applications share the same priority.
Figure 2. Trusty application overview.
Third-party Trusty applications
Currently all Trusty applications are developed by a single party and packaged with the Trusty kernel image. The entire image is signed and verified by the bootloader during boot. Third-party application development is not supported in Trusty at this time. Although Trusty enables the development of new applications, doing so must be exercised with extreme care; each new application increases the area of the trusted computing base (TCB) of the system. Trusted applications can access device secrets and can perform computations or data transformations using them. The ability to develop new applications that run in the TEE opens up many possibilities for innovation. However, due to the very definition of a TEE, these applications cannot be distributed without some form of trust attached. Typically this comes in the form of a digital signature by an entity trusted by the user of the product on which the application runs.
Uses and examples
Trusted execution environments are fast becoming a standard in mobile devices. Users are relying more and more on their mobile devices for their everyday lives and the need for security is always growing. Mobile devices with a TEE are more secure than devices without a TEE.
On devices with a TEE implementation, the main processor is often referred to as “untrusted”, meaning it cannot access certain areas of RAM, hardware registers, and write-once fuses where secret data (such as, device-specific cryptographic keys) are stored by the manufacturer. Software running on the main processor delegates any operations that require use of secret data to the TEE processor.
The most widely known example of this in the Android ecosystem is theDRM frameworkfor protected content. Software running on the TEE processor can access device-specific keys required to decrypt protected content. The main processor sees only the encrypted content, providing a high level of security and protection against software-based attacks.
There are many other uses for a TEE such as mobile payments, secure banking, multi-factor authentication, device reset protection, replay-protected persistent storage, secure PIN and fingerprint processing, and even malware detection.
