New answers tagged

0

Using an https iframe in an http webpage only protect against passive attackers. It is not a good solution because: - It doesn't protect against active attacker (they can rewrite the url of the iframe. see sslstrip) - The browser can't display a padlock for https (because the main page is not secure) The only way to handle securely data is with https on ...


0

I'm sorry you don't need the private key to "decrypt" something encrypted using asymmetric encryption, you need the public key, which is in the certificate, or the certificate of the trusted authority. Using the public key also provides proof that the private key was indeed used. See this prior entry Digital Signature and Verification? and this: how ...


3

Generally speaking†, one cannot intercept HTTPS communications. However, a hot-spot provider can do the following: See the hostnames you want to connect to from your DNS requests See the IP addresses you connect to If you connect to say http://yourbank.com (not https), they can redirect you or serve you their own content. This is one reason why ...


3

If it gets resources from a site like a CDN the certificate will be verified against the URL of this resource, in this case the CDN. The URL of the HTML file embedding these resources does not matter in this case, only the URL of the resource itself. ... with a protocoless path A path like //host/page instead of http://host/page or https://host/page ...


0

Client certificates have all the nicest quality for authentication. But because of a chicken and egg problem users have no reason to acquire a serious certificate (costs money and time because the delivery should be a face to face operation) because few sites use them, and site administrators have no reason to actively support them since their users ...


1

TL;DR Concatenate all but root. It's only required to concatenate site certificate with the intermediate certificate. If there is more than one intermediate certificates you need to concatenate all of them. The "root certificate" is the last certificate in the chain - it's the last because it is self-signed, and no other certificate in the world could ...


0

I work developing a site which offers smart card authentication. The user connects a USB card reader, goes to the site, and when he wants to log in, he inserts the card and supplies a PIN. The issue is that the system uses a Java Applet, and these applets are no longer supported by Chrome or by MS Edge. New middleware is being developed which does not use ...


0

SSL has 2 functions: To prevent the data stream from being decoded by an attacker listening on the network; and To ensure to the client that he is connecting to the authentic server, and not a man-in-the-middle. The first function is not necessary on localhost, because in order to listen to the stream, the attacker would had to have broken into your ...


4

Generally, it is ill-advised to implementing your own session handling. If you can, you would be better off by using a well known and well tested implementation. These are the issues I see in your procedure. User requests password reset How will you handle misuse of this function - will you send one email per reset attempt, or will you implement a ...


1

Universally Unique ID v 4 with device pre registration sounds about right for this sort of application. When a device is in the factory you flash it's firmware with a UUID in it. Then you register that UUID with the DB. If the UUID exists, you generate and flash a new one. This should be exactly what you want because now if someone grabs a device, they have ...


3

You can have multiple valid certificates with the same subject but different keys active at the same time. A possible use with SAN certificates would be to use certificates with the same subject but different key for the different hostnames contained in the certificate. You could even use it for the same hostname (i.e. same hostname on multiple IP addresses) ...


1

This sounds like you are looking for a VPN but want TLS to provide the security (instead of e.g. IPSec). If platform compatibility is not your concern, then Microsoft has developed a Secure Socket Tunneling Protocol which uses such an SSL-VPN scheme. If the "some kind of devices" you are talking about are also Windows-based, then you might not even need ...


7

The order in the ClientHello shows what the client prefers, i.e. the preferred ciphers are on top. The server is still free to ignore this order and pick what it thinks is best. Often there is a related setting in the TLS configuration of the server, like SSLHonorCipherOrder for apache or ssl_prefer_server_ciphers for nginx. Cloudflare at least makes use of ...


1

It is possible that a device may stay un-sold/unused for a couple of years after its manufacture date and most (if not all) CAs will probably be unwilling to issue device certificates that have long expiry dates, so a straight forward solution is perhaps impractical. However, I propose the following alternative: Use alternative method to establish initial ...


0

Points 1 and 2 are addressed by buying a certificate from a trusted CA. As for your second point - 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 If you can find a way to do this, you'll be very rich. or another web page. Eh? I don't understand. ...


1

For TLS 1.2 the signature should be over the two hello nonces plus the ServerDHParams portion of the ServerKeyExchange message. See rfc5246 section 7.4.3 which shows the input to the digitally-signed construct from section 4.7. But note earlier protocol versions are different for RSA signature. Two hashes, MD5 and SHA1, are concatenated, but are NOT ...


4

Any answer to this will be pure speculation: there is no right answer. That said, my opinion is that OpenSSL is at least as good as any closed-source crypto library. Consider that github lists 175 contributors to the openssl project, and 1,442 forks, while google scholar finds 17,400 academic papers for "openssl". Go ahead and find me a closed-source ...


1

The Key principle behind open source software is peer review. The idea is that many people (experts and amateurs alike) will review the code over time and that review process will lead to better, bug free code. So IMO yes, open sourced crypto algorithms are better than closed sourced algorithms for just this fact. However, both systems are still vulnerable ...


-1

X509 certificate validation is covered in RFC 5280. Look at section 6 (https://tools.ietf.org/html/rfc5280#section-6) Conforming implementations of this specification are not required to implement this algorithm, but MUST provide functionality equivalent to the external behavior resulting from this procedure.


0

You could try running synflood against port 443. The client wouldn't be able to connect, and may fail back to port 80. Just a disclaimer, but I haven't tried this. Anyone want to chime in?


1

Certificate validation is done to make sure that the peer is the one you expect. Validating a server certificate in the browser is mainly done by checking that the hostname from the URL matches the name(s) in the certificate and that you can build a trust chain to a locally trusted CA certificate (i.e. the root certificates stored in the browser or OS). ...


8

Let's Encrypt can only issue certificates for valid DNS names. So if your intranet uses a made-up domain name like intranet.mycompany.local then it won't work. If you have a real DNS name like intranet.mycompany.com (even if it doesn't resolve externally to your intranet), then you can use Let's Encrypt to issue certificates for it. If the domain does ...


1

I believe the requirement for public IPs and FQDNs is shouldered by the CA's, not the browsers, so you should be OK (at least, unless someone has better information, you can set up a test in an afternoon and confirm one way or the other). This rules out public certs at a minimum. Of your remaining three options, the best user experience is brought by ...


0

My understanding is of your question is that you ask if the client can use the servers certificate to authenticate against the server, because the client got this certificate within the TLS handshake with the server. If this understanding is correct then the answer is NO because: Only the certificate is send within the TLS handshake, but not the private ...


1

Beware of terminology. Certificates relate to asymmetric cryptography in which keys go in pairs: each pair contains a public key and a private key, which are two facets of the same underlying mathematical object (which depends on the algorithm type). Crucially, the private key cannot be computed from the public key, which is exactly why the public key can be ...


0

It is clear that the certificate authority will issue certificate for fully qualify domain name and validate your domain name, which you want to use for website address. In that case, if you wish to continue with two domain names (www.a.com and www.b.com), then you have two choices as below. 1. Get individual certificates for each You can purchase ...


1

The two options you mention are almost correct: However, you can (and should) install self-signed certificates without them being Certificate Authority certificates. The difference between a self signed cert and a CA cert is that a CA certificate is a special self-signed certificate with its "basicConstraints" set to "CA:true" (usually with the critical ...


0

Apple has released the Security Update 2014-005, disabling the CBC mode with SSLv3: Security Update 2014-005 Secure Transport Available for: OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5 Impact: An attacker may be able to decrypt data protected by SSL Description: There are known attacks on the confidentiality of SSL ...


10

Why HSTS? The weakness HSTS is designed to protect against is clients that first connect to a server by making a request over HTTP, and are expected to be redirected to the HTTPS version (or a 404). An attacker can MitM that request and instead of sending the redirect send the (possibly modified) site over HTTP. Connections over HTTP can be opened for many ...


5

In a scenario where server and client applications were custom-developed and controlled there is no threat model that HSTS would mitigate. Both sides of the transmission should be configured with proper certificates and should prevent protocol downgrade without relying on HSTS. HSTS was introduced as a protection against bypassing SSL by disabling it ...


6

HSTS probably won't make a difference in your case, if nobody ever uses the interface using a browser. If you control the client (which is the other server in your case), you can simply only request HTTPS URLs and never request HTTP requests. It is also questionable whether the client even supports HSTS. It is implemented in many browsers, but not many HTTP ...


0

Just to add to the existing answer, if you want to secure multiple domains using a single certificate, you can explore Subject Alternate Name (SAN) certs, which allow you to protect more than one FQDNs. Quoting from the example given in the linked article: With a Multi-Domain (SAN) Certificate, you can secure: 1) www.example.com 2) ...


4

Certificate validation is done against the hostname given in the URL, which means you'll need a certificate for any hostname which you expect to be used inside a URL. Thus, if you want to use both www.a.com and www.b.com in the URL you need a certificate for each, even if they are the same host and if one redirects to the other. DNS settings like same IP ...


0

Visiting a https url carries with it an expectation of security. Visiting a http url does not. This applies not just when manually typing urls but perhaps more importantly when following links and submitting forms. One soloution to this would be to add another url scheme for "encrypted but not authenticated" but even if all browsers started supporting that ...


6

Click on the 🔒 lock icon in the location bar Click on the “Details” link next to “Your connection to this site is private.” This opens the Security tab of the Developer Tools. Reload the page. The Security thing’s left column goes “🔒 Overview”, “Main Origin”… Click on the next one, “⚫ https://security.stackexchange.com”. Connection ...


3

Your Tor software comes with a list of predefined directory authorities. These authorities maintain signed lists of relays from which your client can choose to build the connection. A new relay publishes a server descriptor to the authorities to advertise itself. Since not every Tor client acts as a relay, the number is smaller than you might assume and you ...


3

If you enable SSL/TLS on the server side, the client has to be able to "speak SSL/TLS" too. Otherwise, the connection will end up being reset. Just changing a web-service to use "https" does not auto-magically change all applications communication encrypted. This is a shared protocol. If I suddenly goes speaking French but you only understand English, ...


1

Properly validating a certificate is a really complex matter. As with many things in crypto, it's best to leave this validation to a library instead of trying to implement it yourself. Typically, you'd ask your library to perform all the hard work and then check for any additional properties you are interested in afterward. As for the details: First, you ...


0

Whitelisting is technically narrowing the possible threats to you to the ones that actually target you specifically. By denying large amount of more general threats through whitelisting you can let your encryption work on full power against a much smaller chunk of threats that can go through whitelisting.


1

And you should make a lot of checks about the cerificate genuinity, i.e. to avoid MitM or false-issued certificate by "so-called stolen" CA key. Take a look and star at Perspectives Project to have a full picture


1

If you configure the server to redirect HTTP to HTTPS, you shouldn't need to modify the application code whatsoever (assuming it will follow a redirect). However, when the request is first made, it will not be encrypted. An attacker could man-in-the-middle or passively sniff the connection in order to read request data or even prevent it from redirecting to ...


0

Private keys should exist only in one place. If you distribute the private key to "authorized users", then the "authorized users" have all access of the original, and cannot be revoked. The correct method would be: All devices share their public key, never their private key. The public key is approved by the account holder. Any changes logged should ...


3

When talking about security (in general), it is important to think about what problems you are attempting to solve, and what tools you are using to solve them. These have to align. If the problem you are attempting to solve is general attacks from the internet, then whitelisting may be a useful tool - to overcome whitelisting, you have to be somewhere on ...


0

Just because you add https to your web server does not mean that you have to remove http. For example, this very page is available both over http, and over https. While it's certainly a good idea to migrate your Android app to use https, you don't have to do it right away: offer both!


4

There is no security impact to either stop or continue the handshake -- the security relies in the tests performed by the client, not the server. This is why the extension is called an indication. What matters is that the client duly verifies that the apparent server public key is really owned by the intended server. The SNI is a way for the client to convey ...


13

If the data is unencrypted, anyone sniffing the packets between your server and their server can see it. A whitelist only lets their server verify that the source of the data. It doesn't assure that no one sniffed it during transfer, or that it wasn't intercepted and manipulated at any point during the process. In short, encrypt the data, keep the whitelist ...


64

The sniffing problem is about "confidentiality", which whitelisting does not cover, as the traffic can be intercepted and read. The MitM problem is about "authenticity", which whitelisting does not cover either, as an intercepted packet can be modified without evidence of tampering. I assume the whitelisting uses IP addresses, which can be arbitrarily ...


33

This is an historically disputed point. In the validation algorithm from RFC 5280 (that supersedes RFC 2459, by the way), there is no requirement of validity range nesting. However, some historical implementations have insisted on it; see for instance the X.509 style guide of Peter Gutmann: Although this isn't specified in any standard, some software ...


14

Hmm, I agree that I would have expected to find this info in RFC 5280 4.1.2.5. Validity. (By the way, RFC 5280 obsoletes RFC 3280, which obsoletes RFC 2459, so you really shouldn't be looking at 2459 any more). That said, you can figure this one out logically (at least for a standard TLS-like setting): When an end-user validates a cert, they have to follow ...


1

But I was not able to understand why simple RSA_DH does not support forward secrecy. Lets say alice is the client and Bob is the server and use the variable names from your diagram. In non emphreal dh b is part of the certificate which means B is a long term secret. Eve records the session including the value of a. Some time later Eve gets hold of B, ...



Top 50 recent answers are included