In verifyHostName of OkHostnameVerifier.java, there is a possible way to accept a certificate for the wrong domain due to improperly used crypto. This could lead to remote information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-8.1 Android-9 Android-10 Android-11Android ID: A-171980069

An insecure communication was found between a user and the Orpak SiteOmat management console for all known versions, due to an invalid SSL certificate. The attack allows for an eavesdropper to capture the communication and decrypt the data.

Dell BSAFE Micro Edition Suite, versions prior to 4.5.1, contain an Improper Certificate Validation vulnerability.

RSA BSAFE Crypto-C Micro Edition versions prior to 4.1.4 and RSA Micro Edition Suite versions prior to 4.4 are vulnerable to an Information Exposure Through Timing Discrepancy. A malicious remote user could potentially exploit this vulnerability to extract information leaving data at risk of exposure.

Pivotal Application Service (PAS), versions 2.2.x prior to 2.2.12, 2.3.x prior to 2.3.7 and 2.4.x prior to 2.4.3, contain apps manager that uses a cloud controller proxy that fails to verify SSL certs. A remote unauthenticated attacker that could hijack the Cloud Controller's DNS record could intercept access tokens sent to the Cloud Controller, giving the attacker access to the user's resources in the Cloud Controller

iScripts SocialWare stores passwords in cleartext in a database, which allows context-dependent attackers to obtain sensitive information.

CRE Loaded 6.2.13.1 and earlier does not set the "Secure" attribute for cookies that are sent over HTTPS, which might allow remote attackers to sniff the cookies if they are sent over HTTP.

The host name verification when using TLS with the WebSocket client was missing. It is now enabled by default. Versions Affected: Apache Tomcat 9.0.0.M1 to 9.0.9, 8.5.0 to 8.5.31, 8.0.0.RC1 to 8.0.52, and 7.0.35 to 7.0.88.

WebCore/platform/network/soup/SocketStreamHandleImplSoup.cpp in the libsoup network backend of WebKit, as used in WebKitGTK+ versions 2.20.0 and 2.20.1, failed to perform TLS certificate verification for WebSocket connections.

An issue was discovered in Squid 5.0.6 through 5.1.x before 5.2. When validating an origin server or peer certificate, Squid may incorrectly classify certain certificates as trusted. This problem allows a remote server to obtain security trust well improperly. This indication of trust may be passed along to clients, allowing access to unsafe or hijacked services.

An issue was discovered in Mattermost Server before 3.0.0. It does not ensure that a cookie is used over SSL.

The D-Link DIR-615 device before v20.12PTb04 doesn't use SSL for any of the authenticated pages. Also, it doesn't allow the user to generate his own SSL Certificate. An attacker can simply monitor network traffic to steal a user's credentials and/or credentials of users being added while sniffing the traffic.

Icinga is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. In versions 2.5.0 through 2.13.0, ElasticsearchWriter, GelfWriter, InfluxdbWriter and Influxdb2Writer do not verify the server's certificate despite a certificate authority being specified. Icinga 2 instances which connect to any of the mentioned time series databases (TSDBs) using TLS over a spoofable infrastructure should immediately upgrade to version 2.13.1, 2.12.6, or 2.11.11 to patch the issue. Such instances should also change the credentials (if any) used by the TSDB writer feature to authenticate against the TSDB. There are no workarounds aside from upgrading.

Versions of the puppetlabs-apache module prior to 1.11.1 and 2.1.0 make it very easy to accidentally misconfigure TLS trust. If you specify the `ssl_ca` parameter but do not specify the `ssl_certs_dir` parameter, a default will be provided for the `ssl_certs_dir` that will trust certificates from any of the system-trusted certificate authorities. This did not affect FreeBSD.

It was found that CloudForms does not verify that the server hostname matches the domain name in the certificate when using a custom CA and communicating with Red Hat Virtualization (RHEV) and OpenShift. This would allow an attacker to spoof RHEV or OpenShift systems and potentially harvest sensitive information from CloudForms.

Nextcloud Android Client is the Android client for Nextcloud. Clients using the Nextcloud end-to-end encryption feature download the public and private key via an API endpoint. In versions prior to 3.16.1, the Nextcloud Android client skipped a step that involved the client checking if a private key belonged to a previously downloaded public certificate. If the Nextcloud instance served a malicious public key, the data would be encrypted for this key and thus could be accessible to a malicious actor. The vulnerability is patched in version 3.16.1. As a workaround, do not add additional end-to-end encrypted devices to a user account.

Inappropriate implementation in BoringSSL SPAKE2 in Google Chrome prior to 63.0.3239.84 allowed a remote attacker to leak the low-order bits of SHA512(password) by inspecting protocol traffic.

IBM InfoSphere Data Flow Designer Engine (IBM InfoSphere Information Server 11.7 ) component has improper validation of the REST API server certificate. IBM X-Force ID: 201301.

A flaw was found in stunnel before 5.57, where it improperly validates client certificates when it is configured to use both redirect and verifyChain options. This flaw allows an attacker with a certificate signed by a Certificate Authority, which is not the one accepted by the stunnel server, to access the tunneled service instead of being redirected to the address specified in the redirect option. The highest threat from this vulnerability is to confidentiality.

An issue was discovered in Erlang/OTP before 23.2.2. The ssl application 10.2 accepts and trusts an invalid X.509 certificate chain to a trusted root Certification Authority.

A vulnerability has been identified in SIMATIC HMI Comfort Panels 4" - 22" (All versions < V15.1 Update 1), SIMATIC HMI Comfort Outdoor Panels 7" & 15" (All versions < V15.1 Update 1), SIMATIC HMI KTP Mobile Panels KTP400F, KTP700, KTP700F, KTP900 und KTP900F (All versions < V15.1 Update 1), SIMATIC WinCC Runtime Advanced (All versions < V15.1 Update 1), SIMATIC WinCC Runtime Professional (All versions < V15.1 Update 1), SIMATIC WinCC (TIA Portal) (All versions < V15.1 Update 1), SIMATIC HMI Classic Devices (TP/MP/OP/MP Mobile Panel) (All versions). An attacker with network access to affected devices could potentially obtain a TLS session key. If the attacker is able to observe TLS traffic between a legitimate user and the device, then the attacker could decrypt the TLS traffic. The security vulnerability could be exploited by an attacker who has network access to the web interface of the device and who is able to observe TLS traffic between legitimate users and the web interface of the affected device. The vulnerability could impact the confidentiality of the communication between the affected device and a legitimate user. At the time of advisory publication no public exploitation of the security vulnerability was known.