Tag Info

New answers tagged

2

What you are describing is actually your own, reduced auto-update feature, limited to updating what amounts to a "trust store" for certificates. The bad thing about it is that it works outside of the normal app update mechanism, without much possible user intervention, so the user will get the updates whether he wants them or not. The good thing about it ...


0

Yes you need to trust on that self-signed certificate Certificate because you have added it in your browser. But to create a new certificate signed by this CA you must have private key of the CA. So no body else can create certificate signed by your CA.


0

There's a very interesting use case in this other answer, using client-side certificates: Why would the BBC web site always ask for a personal certificate, and how do I avoid giving it away? Another quick-and-dirty option might be implementing a VPN and shifting the domain of the problem from PHP to system administration. This might prove useful if, in the ...


0

thats long story, can't comment so leave as link here Using SSL Client Certificates with PHP also you may take look at apache SSLRequire Directive may a bit sorter story also PHP OpenSSL module php.net/openssl plenty of stuff around that question


0

You could setup SSL and create your own certificate. I believe there is an option to create something like client approved certificates. That means that you need to install the client part of the certificate on the client (the browser). If the client doesn't have this installed, it won't work. To be honest - this is something that I read about last week, ...


0

Limiting access for the web browser (user-agent) is something that is very easy to manipulate using a tool like Tamper data. You can change the header to make it look like the request is coming from any browser you want. If you want to make sure they can only access the website from the office (if this is one location) you could restrict access based on IP ...


0

If you are using PHP web application, you can use this function to check client browser.


0

On the server, it's easy to check the headers of each HTTP request (the User-Agent header, in your case) and redirect to a landing page that explains why the browser can't be used, and which browsers are supported. You'll need to install a form of authentication to validate requests originating from unauthorized clients. Installing an X.509 certificate on ...


2

If the client's initial request is for HTTPS, then the client will insist on first doing the SSL handshake, and only then, within the newly created SSL tunnel, will the client send the actual HTTP request, the one you want to respond to with a 301 code. This means that if the client entered the https:// URL (either he typed it, or followed a bookmark which ...


1

If the client specifically types in https in their browser, then you couldn't do what you are saying as the browser would first request the certificate before allowing you to send the 301 redirect. You don't have a valid certificate for the domain, so the user would see a certificate exception. If the client does not initially try to set up an HTTPS ...


0

Apart from using OpenSSL to see what your server responds, you can also write some code with the SSL library of your choice to test specific aspects. For instance, I wrote TestSSLServer to obtain the list of cipher suites and versions used by a server, and test for potential vulnerability to BEAST and CRIME. None of these tools will give you a "rank". There ...


1

You can reduce the number of probes that Nmap sends by using the --version-intensity option. This option takes an integer argument between 1 and 9, limiting the number of probes sent to open ports to those with a rarity of that number or less. The probe for SSL/TLS (SSLv3 and newer) has a rarity of 1, so you could get away with a simple --version-intensity ...


1

To really know what is happening, you should not set your Linux machine as a proxy but as a router. The "proxy" really is an HTTP proxy. Applications which want to do HTTPS (HTTP-within-SSL) may use the system settings and use a CONNECT method to make your proxy forward the traffic in both directions; but they may also connect directly to the serve, ...


3

Train users to either always type https:// for your site, follow links from a site like google (that has hard-coded HSTS), or use a bookmark. (Do this training in addition to other sensible training policies: do not do security sensitive things on unsecured/public wifi or public computers, use strong passwords that aren't reused, etc.. Then try getting ...


0

The only way is to not offer any sensible data (this includes login forms already) on port 80. This way the client must switch to https, either by hand or automatically through redirection etc.


0

Correct, your token needs to kept secret, or an attacker can duplicate the token. It's harder than borrowing the session cookie, but the basic principle is the same. If you generate a unique CSRF token for every request & require it be used only once and on ever request, you can then ensure the token is not replayed. Even then it's still possible for ...


1

If an attacker can sniff the CSRF token, then he can also sniff the session cookie and there would be no reason for him to launch a CSRF attack. Or am I missing something?


0

The openssl in ubuntu does not support TLSv1.2, They have disabled it. It is documented in bug 1256576


0

nedR, after viewing the GnuTLS site, I found that any versions prior to version 3.2.12 or 3.2.22 are still vulnerable. The Ubuntu packages using GnuTLS 28 are mostly still affected. That is, packages 12.04, 12.10, 13.10, and 14.04. Glad to be of assistance!


0

Can you explain exactly how the other browsers fall back? I've seen the following scenarios with servers and middleboxes: try to connect with TLS 1.0 or higher, peer responds with SSLv3 and thus the connection continues with SSLv3. This usually succeeds. try to connect with TLS 1.0 or higher, peer closes connection and browser tries again with lower TLS ...


5

I find the question useful, because it is actually hard to find out if a certificate got revoked the right way. If you know who issued the original certificate you can download the CRLs (which contains only the serial numbers and the date of revocation, not the revoked certificate itself). If not you are out of luck. If you know the serial number of the ...


-1

rule of thump: if open-source-server (e.g. apache, nginx, lighttpd et al) AND if tls 1.2 is available then the service was most probably affected by heartbleed


2

As Wikipedia says, in its infinite wisdom, "idem" is a Latin word and means "the same": Id. (masculine and neuter) and ead. (feminine) (Latin, short for idem and eadem, "the same") are the terms used to denote the previously cited source In this case, this means that the list of cipher suites for TLS 1.0 is strictly identical to the list for SSL 3.0, ...


0

The ECDHE-RSA-AES128-SHA cipher suite means that the key exchange will use a dynamically generate ECDH key pair, that the server will sign with its own RSA private key. The server's certificate will thus contain a RSA public key, regardless of how that certificate was signed by its CA. I suppose that the certificate you use contains an EC key pair, thus not ...


0

There was an answer here that has since been deleted that was really interesting, at least in the comments it provoked. Essentially, the answererer was (not very clearly) trying to say that each new allocation of buffer to read the heartbeat from changes the start address, and because you are able to run the attack many times, you are able to randomly pull ...


-1

You are using ECC with ecdsa-cert.crt, so you should specify command option -cipher ECDHE-ECDSA-AES128-SHA.


0

Turns out the problem had nothing to do with the certificate and everything to do with the fact that the client was coming in over the VPN. When the client was physically on the network, everything worked fine. I ended up having to change the MTU on the ubuntu server and everything worked fine.


1

As Terry says, the main advantage is that it offers information-theoretical security. But on a couple of points you mentioned in the rest of your question: The length is not an advantage in itself but the fact it means you can never prove what you derived from a guessed key is the actual decrypted data makes it infinitely secure - provided you do not fall ...


1

Let's assume, for an instant, that you really need to "re-key your Web servers" because of the heartbleed bug (if there is such a need, then you quite logically also need to do it for every other similar vulnerability which shows up, hence several times per year, and you must also do it for vulnerabilities which will show up, so, by that reasoning, your ...


1

It is extremely important to understand that "One Time Pad" is an element of the actual cipher used, not any particular protocol. For example, SSL or TLS using RC4 is, effectively, implementing a digital One Time Pad, while SSL or TLS using DES or AES is not using one. One Time Pad refers to the old-school cryptographic technique of printing code pads... ...


1

Let C be the attacker. C runs another server, under its own name (C), with its own public key Kc. Occasionally, A connects to C (knowingly, but not knowing that C is Evil, or believing that the evilness of C won't extend beyond C itself). Attack goes thus: Client A connects to C and sends {Kac}Kc to C. Immediately, C connects to server B and claims to be ...


1

You assume incorrectly: a cert does not have to be revoked when re-issued. It is typically a different process altogether. This means that you should add a last step to your plan: revoke the old certificate once you are done with installing the new one. Clients will not cache your certificate. In fact, they cannot keep a cached copy since it is your server ...


5

It is a matter of redundancy of information. An attacker wants to decrypt some piece of data, because he is interested in that data, and thus has context information. For instance, assuming a HTTPS connection, the attacker knows that what is encrypted is an HTTP request and an HTTP response, both coming with syntactically correct HTTP headers. It is highly ...


8

A one time pad offers information theoretic security. This essentially means that the one time pad cannot be broken even if the adversary has unlimited computing power. This is because XOR-ing any data against a truly random key will guarantee that the output be random as well because you are simply flipping bits.


0

There are a a few cases where checking the hash of a file could be prove a security benefit, even if the hash wasn't downloaded through a secure connection: If only your connection is being tampered with, you could visit the web page containing the hash using another connection (e.g. a secure VPN). If the page, when viewed through that other connection, ...


0

For the exact answer, refer to the standard. For a short summary: the sequence number is implicit and is not transmitted. Both sender and receiver keep track of how many records they sent and received, so they don't need it to be repeated in the record itself (and if it was there, then they would have to verify it, because the point of the sequence number ...


2

To be exact, the RFC recommends legit heartbeats be done after handshake completes; it doesn't recommend exploits ever. (Compliant with http://tools.ietf.org/html/rfc3514 which sadly never made it to BCP.) Yes, Heartbeat is a distinct record type (24 or 0x18). Any response longer than the request by more than reasonable padding is proof of exploit. Any ...


22

For TLS with the purpose of liveliness (keep-alive) checks, there's no reason to: Encode a payload size field in the heartbeat request/response header (the length of the payload comes from the record layer rrec.length in OpenSSL code -- you just have to subtract off the fixed HB header size from this), Allow HBs to be variable size -- a small HB size (in ...


1

Thomas has already written an excellent answer, but I thought I'd offer a couple more reasons why HTTPS is not more widely used... Not needed. As Jesper's answer insightfully points out "the majority of information on the web doesn't need security". However, with the growing amount of tracking taking place by search engines, ad companies, country-level ...


32

I am not aware of any definitive, "official" answer on this subject, but this seems to be part of an attempt at genericity and coherence. In the SSL/TLS standard, all messages follow regular encoding rules, using a specific presentation language. No part of the protocol "infers" length from the record length. One enlightening detail is the ClientKeyExchange ...


13

If you look into the RFC6520 (heartbeat extension) there is a padding after the payload. So the length is required to know where the payload ends and the padding starts. Apart from that I find the design overengineered: the both reasons for this extension seem to be to make PMTU possible (by using messages of different size) and by heaving heartbeat to know ...


4

The Change Cipher Spec message means: from now on, records will be encrypted with the newly negotiated cipher suite and keys. So all subsequent records will be encrypted, and that's what you observe: an encrypted record. Of course you cannot see the contents: that's the point of encryption. Right after the Change Cipher Spec follows a Finished message, ...


1

Good Question. TACK is a "dynamic pinning" solution to the broken Certificate Authority model we all depend on today. A competitor is Google's Certificate Transparency (CT). Status of TACK is No browsers currently support it. There are no browser extensions to enable it. The last posting from the developers (January, 2014) is that it is entirely up ...


3

The Heartbleed bug indeed allows other parties to read memory outside the intended space, but it does not allow you to read memory from other processes. The start address cannot be modified either by the attacker, it really depends on the memory allocation algorithm which memory ends up to be returned. Most likely this is memory of a recent HTTP request (for ...


1

Might be well worth the effort to have a look at KeePass Password Safe, an offline password manager. I use it and am very happy with it. Perhaps also check out Wuala, a cloud data storage service similar to Dropbox, OneDrive, and Google Drive. Wuala is different because it encrypts your data locally before storing it on their servers (Wuala only stores your ...


0

No, a SSL server does not sign what it returns. The operations which use asymmetric keys and may qualify as signatures occur during the initial steps of the connection (the "handshake"), before any applicative data is sent, so these operations cannot logically bind anybody to the contents of such applicative data. There is a possible source of confusion, ...


1

HTTPS does not sign a document; it does not provide any lasting affidavit as to the provenance, legitimacy, or validity of the document. A signature is a modification to or verifiable description of a document which can be used at a later time to validate the document or the fact of that document's authorship or review by an entity. As such, there must be ...


0

As already mentioned in the comments, the HTTPS protocol does not sign a document. It merely uses the SSL/TLS protocol to encrypt and decrypt on the transport layer of the OSI model, by using a certificate (which contains the public key used to encrypt/decrypt data on clients) from the Public Key Infrastructure (PKI).


2

One theory is that, ideally, the end-user should manage his own store of trusted root CA, making an informed decision based on the published Certification Practice Statements by existing CA. Theory and practice match only in theory, though. It is not surprising that most users cannot and will not handle such a management process, if only because it relies ...


2

The private key is need by Firefox for client authentication, i.e. when the client demonstrates to the server ownership of a certificate. By definition, this requires knowledge of the private key on the client side. This does not happen often, because most Web servers authenticate clients with passwords, not with certificates. Of course, Firefox has no need ...



Top 50 recent answers are included