New answers tagged

0

At least a workaround for macOS 10.15.4: I encountered the same issue today in conjunction with the codecov bash script. My quick fix: brew install curl and do what brew link curl suggest. You can check if you've picked the right curl with which curl (should point to /usr/local/opt/curl/bin/curl). I have no time or patience to wait for 🍏 to fix those ...


1

All these sites that I have found seems to have the same expired CA cert in their chain: openssl s_client -connect kapeli.com:443 CONNECTED(00000003) depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root verify error:num=10:certificate has expired notAfter=May 30 10:48:38 2020 GMT I see issues popping up on ...


4

Root CA certificates used by the mentioned sites (Comodo and USERTrust) have expired this morning (UTC time). While I find it remarkable that two different Root CA certs would expire at the exact same second, this may be explained by USERTrust being affiliated with Comodo (now Sectigo). Now, updated certificates (sharing their private keys with the expired ...


3

There's no "free EV", "EV for localhost", nor commercial certificates for the localhost in the first place. Also, there's no separate "SSL for Pentest"; if there was a service providing arbitrary certificates for everyone claiming they are penetration testers, the whole PKI would lost its credibility: Claiming good intention doesn't rule out that the ...


6

No. They do not have and they will not issue such certificate. The CA/Browser Forum Baseline Requirements forbid to issue a certificate for a shared resource, such as localhost or a rfc 1918 IP. Not to mention that an EV certificate would mean they thoroughly validated you were the owner of localhost, which you clearly aren't. You can create your own CA ...


-2

According to Qualys SSL Lab, BEAST is no longer relevant due to client side mitigations: https://blog.qualys.com/ssllabs/2013/09/10/is-beast-still-a-threat


0

TLDR: if you are dealing with your own application, many issues should have a higher priority than this; if you are dealing with security auditors, yeah, most likely you will need SSL cert for ALB. It's up to what kind of risk you can accept. Some government projects don't allow any risk from internet, so they are in intranet. Before we start, you should ...


1

PEM files are base64 encoded binary data, this is a defined standard (so there's nothing to prove here). The reason for this encoding is spelled out in the intro of RFC 7468: A disadvantage of a binary data format is that it cannot be interchanged in textual transports, such as email or text documents. One advantage with text-based encodings is that ...


2

Within a man in the middle attack the attacker is in the path between client and server and can thus sniff and manipulate the traffic. This is for example possible if the attacker is a government agency which has sufficient control over the traffic leaving and entering the country, as it was true with Iran in this specific case. In the context of SSL this ...


2

Benchmarks on a single core in my aging laptop (Skylake, openssl 1.1.1): $ openssl speed rsa2048 rsa3072 rsa4096 sign verify sign/s verify/s rsa 2048 bits 0.000662s 0.000020s 1510.2 49977.8 rsa 3072 bits 0.002078s 0.000040s 481.2 24920.9 rsa 4096 bits 0.004433s 0.000068s 225.6 14614.6 $ openssl speed ecdsap256 ecdsap384 ...


2

One of the points of TLS is to solve this problem - a secure way to transport data across untrusted networks, preferably using ephemeral keys for the actual encryption portion. Doing this yourself is possible but is coming dangerously close to "rolling your own" as you will have to solve problems like key storage, etc. Depending on how your backend network ...


10

Considering that TLS is in place with a solid configuration (i.e. certificate pinning), which I find no reason not to, you'd need to work out the business risk you're trying to mitigate by encrypting this information. Ask yourself, what would you gain by doing this? What type of attack vectors are you mitigating? How are you going to generate, distribute ...


-1

The standard practice is to use https for the baseline protection of REST API calls. Additionally (going beyond standard practice, but preferred by some), selected information that is sent to the server or received from the server, may be further encrypted with AES, etc. For example, if there are sensitive contents, you might choose to select those to ...


0

If cipher suites really matter, does it mean that attacker can specify certain cipher suite for handshake to make the attack more likely to succeed? Conceptually yes, though not with sslsqueeze. It is a simple tool that seems to be hardcoded to establish SSL and TLS connections with RSA key exchange (I've briefly read the code, a deeper analysis might ...


0

TLS Cipher suites define several parameters including key exchange, encryption and hashing and must be agreed between clients and server. The use of RSA or ECC certificates does require different key exchange parameters (specifically *_RSA vs *_ECDSA). Whilst just about everything else can be the same in a TLS connection, the actual cipher suite definition ...


0

I'll just answer it since I figured it out by looking at the picture below and since no has given the simple direct answer and I'm getting downvoted for it. Because Bob's public key is sent with the certificate, the ISP cannot send it's own certificate because no CA will trust it and therefor Alice's CA public key will fail to decrypt an ISP provided ...


1

There's two pieces to enabling TLS's security model, which yes, does protect an ISP from being able to see the contents of messages between you and a destination server. The first, as you've mentioned is the certificate signed by a CA. However, the important thing to understand is what the private key assosciated with the certificate is used to sign: A ...


3

First retrieving arbitrary non-existing resources like /test.xml isn't within normal operation of your site, and therefore the problem doesn't exist anymore after the browser has seen the HSTS header somewhere (or preloaded it), as it causes upgrade to HTTPS on hostname level (and domain level with includeSubDomains). Also, it doesn't make a huge difference ...


4

Suppose attacker tricks victim to click on link to your site, browser uses http, attacker in strong network position intercepts and sends malicious content and makes victim believe content came from your site. How would HSTS help? If the victim visited your site before, their browser has an HSTS "flag" for the domain, and clicking the link would make the ...


0

How far does the HTTPS protection go? That depends what the adversary does with the proxy. If all they do is logging and forwarding, then the adversary will see limited amounts of detail (for example, the host name of the server), but the rest will be protected by TLS. If the proxy tries to break the TLS connection and act as a "real" proxy, then you will ...


1

What is span of the HTTPS protection? Does it protect traffic between client and destination or is it only in between proxy and destination? With a HTTP proxy the client requests a tunnel to the server (using HTTP CONNECT request) and then creates an end-to-end TLS session between client and server over this tunnel. A non-intercepting proxy will only ...


3

For security purposes, a certificate's signature must sign the entire certificate (aside from the signature itself, obviously...). Otherwise, you could take a validly-issued certificate for your own domain (and for which you hold the corresponding private key), change the "Subject" (the entity - such as a domain like "yoursite.com" - that the certificate ...


1

You'll need to add the NameConstraints extension to the request using LibreSSL's config file. The following example is an extract - you'll need to add the various sections to your current config file and tweak the constraints: [ req ] # Don't prompt for the DN, use configured values instead # This saves having to type in your DN each time. prompt ...


7

The signature covers the certificate, not only the public key. If the signature covered only the public key, you could change any parameter (expiration date, domain name, issuer) and the signature would still be valid. Digital signatures are not encryption: https://security.stackexchange.com/a/87373/70830 It is important, when reading the link above, to ...


1

This article, under BREACH sums it up pretty well. BREACH targets HTTP compression, not TLS compression With that said, the random record padding can be done on a higher level of encapsulation and not on the TLS record itself. You do not want to be obscuring the length of the record but the whole response. Here are the preventive measures mentioned in ...


6

No, there is no way to bypass certificate pinning without application patching or using debugger (tracer). The reason is that, in simple words, certificate pinning is when a CA certificate is hardcoded into application. This application sets the certificate as the only root of trust to establish a network connection. On Android it's carried out via ...


0

If you are asking if there is a way to decrypt TLS data without rooting your device or patching the executable, the answer will probably be no. But if you are asking if there are some other ways you can decrypt TLS data without having to bypass TLS certificate pinning. For example, this is a little tool I've made for decrypting TLS data on iOS devices ...


0

Because it lacks a filter to correctly identify this protocol's data stream as being TLS. As discussed in the comments, it's not a straight-forward TLS over TCP connection.


0

Sinse you don't see any cookies, means you store user credentials on the client. It means that either you ask user for credentials for every single request, which is a poor usability. Or you have fields for user and password, user enters these data once and they remain in the current page the whole time over multiple requests. If this is true, this is not a ...


1

Chuck Company could spoof trusted certificates if they provide their users with managed devices. But it cannot actually replicate Verisign certificates, they could just fake end-users with managed devices. Because end-users couldn't validate certificate from authorized CAs. Chuck Company could hide their inspection to TLS connection from Alice TLS will be ...


1

The thing about TLS 1.3 is that both parties do not need to be within a single timeframe to be performing the handshake, or share time-related information at the start. TLS 1.1 & TLS 1.2 however, had a time element in its Client Hello message TLS 1.1 & TLS 1.2 Client Hello Message, Structure of this message: The client hello message includes ...


0

During TLS negotiation (at least in 1.2 and below, I'm not sure how 1.3 changes things), the client and server agree a "ciphersuite". Basically the client sends a list of ciphersuites in order of preference and the server picks one, the server is supposed to respect the client's preferences but not all do. The server must pick a ciphersuite that is ...


1

Based on info added in comments: Are you using late-ish java 8 i.e. after about 8u90? In those versions keytool -list with storetype defaulted to JKS will actually read PKCS12 but still show JKS. Assuming so, 'chain length: 1' means you did NOT put the chain cert in the keystore, thus the server's cert chain is incomplete and can't be validated. So: Get ...


0

The solution is provisioning the devices at the factory with unique verifiable certificates. But nobody does this. Also some of your requirements are not realistic (as mentioned above): If the private key of the device was compromised, an attacker should not be able to use this key to perform MitM attack against another device or another web page. Not ...


1

I would not assume that any of the certificate extensions are the error cause in this case. For me, the errors look like both sides don't trust the certificate of the other side. You could use a packet sniffer like wireshark to take a closer look at the handshakes. Do both client and server send exactly the certificate you expect them to? Also, do verify ...


0

In very broad terms, Diffie-Hellman (DH) is a key exchange algorithm that allows for parties with no prior knowledge to agree a shared secret, with this process happening securely over an insecure medium. In other words, the full negotiation can be analysed by an attacker and by design will take cryptanalysis to extract the secret key. DH is used in some ...


-1

A VPN is a Virtual Private Network whereby traffic flows within an encrypted tunnel across networks. Often this is used to route Internet traffic from an arbitrary client, via a VPN server outside its network onto the Internet. This has the advantage of protecting client traffic in its local network, until it reaches the first router on the Internet. Traffic ...


1

OpenVPN checks the content of certificates following the values of remote-cert-tls which should be server on clients and client on the server (this is correct on your configuration). Please don't use ns-cert-type as it is deprecated since OpenVPN v2.4/v2.3.18, so there's no need to enable EASYRSA_NS_SUPPORT. Therefore, client certificates should have "...


1

What would such certificate be able to achieve, specifically about MITM type attacks? For Bob, the attacker is Alice. The attacker says he is Alice, and gives him Alice's certificate. He will ask Bob for his certificate, and Bob will give him. A compromised CA means anything signed by that CA is compromised, and useless. Every single issued certificate ...


1

I just had the same issue and wanted to share my 'solution'. I was stupid enough to have ./easyrsa sign-req server client01; which produced the same error: TLS: Initial packet from [AF_INET]***:***, sid=*** *** VERIFY ERROR: depth=0, error=unsupported certificate purpose: C=.., ST=.., ... OpenSSL: error:***:SSL routines:ssl3_get_client_certificate:...


0

You misunderstand how TLS works. A certificate signing request is exactly what it sounds like: A request for a certificate authority to sign a certificate. The request alone is worth nothing. Compare that with the request to be released from prison, compared to a signed pardon letter. As Z.T. pointed out in a comment, the requests needs to be signed from a ...


2

The operator of the domain either uses Cloudflare as registrar or user another registrar and points the domain to Cloudflare's authoritative DNS servers. This gives Cloudflare control over the domain, and they are able to issue valid TLS certificates for the domain, as they host it. Cloudflare also host the authoritative DNS servers that reply with ...


1

RFC 8446 (TLS 1.3) says: Implementations are responsible for verifying the integrity of certificates ... Absent a specific indication from an application profile, certificates should always be verified to ensure proper signing by a trusted certificate authority (CA) The spec seems to say that verification needs to be supported, but doesn't exactly ...


2

If I understood correctly, your peer's client-side certificate is not trusted by your organisation. Your ops team would have asked for a CSR to return a signed certificate that you trust, so that their (new) client-side certificate becomes trusted. Unless there's more involved that isn't clear in the question, you don't need to send them a CSR, since your ...


3

See answer by Thomas Pornin at https://crypto.stackexchange.com/questions/5455/does-a-trace-of-ssl-packets-provide-a-proof-of-data-authenticity. Like the other answers here, Thomas Pornin explains that the signature by the client cannot be used to prove anything about the information that the client sent to the server during the session. However, the ...


8

No. There is an even simpler scenario for this question, without the client certificate. You ask, given pcapng / tcpdump / wireshark file of the entire communication session between client and server and an SSLKEYLOGFILE dump in NSS Key Log format so you could decrypt the stored traffic, is that proof that the server sent whatever the file says the server ...


3

The certificate of the client is only used to authenticate the client. It is not used in key exchange which happens before the client even sends the certificate and proves ownership of the private key. The client certificates is thus neither directly nor indirectly included in the traffic encryption or MAC. This means that capturing the TLS traffic can not ...


1

Given your previous question it looks like you are talking about an IoT environment, i.e. IoT devices which communicate with a server via mutual TLS. In this environment you very likely don't use certificates issued by a public CA but instead use a private CA. The limit of 2 years you mention is only enforced by public CA. If you run your own CA and have ...


1

I am not an expert of hardware manufactoring but here are my 2 cents on the topic. Step one: set up a root PKI On your server, you should create a custom Certification Authority (see my comment) that will be used later to sign all certificates. Configure your server to trust only that CA Step two: you need an extra manufacturing step to enroll the devices ...


1

If the requirement is that the server can authenticate a client device immediately after the device was first switched on then there is no other way but to ship devices where each has a unique certificate in the firmware or associated data. How this can be accomplished depends on the process how these devices are produced, i.e. how the firmware ends on the ...


Top 50 recent answers are included