Hot answers tagged ssl
12
If the only user on the database that can change records is root and your CMS uses the root user to perform queries then you have a problem. Your root user should never be used by a website.
Get a limited user which can only access the tables and records he needs to access restricted with the right permissions. If he doesn't need delete or update, then ...
12
Get a known clean version of your site and identify the differences between the known good code the and current (hacked) production code. Study how the changes may have been made and repair.
Update the passwords.
Fix the FTP certificate issue - consider using 2 factor authentication.
Find a way to scan your code for vulnerabilities - peer review or ...
8
There is a handy script distributed alongside openssl, CA.sh to do most of this stuff. Its location is distribution specific. In Debian and derivatives you can locate it using:
# apt-file search CA.sh
openssl: /usr/lib/ssl/misc/CA.sh
And RedHat and derivatives the (approximate) equivalent is:
# yum provides */CA
1:openssl-1.0.1e-4.fc18.x86_64 : Utilities ...
6
The same question had come up in stackoverflow some time back,please find the link below.
http://stackoverflow.com/questions/893959/if-you-use-https-will-your-url-params-will-be-safe-from-sniffing
To summarize the answers mentioned in the link, the url parameters that are sent to the server will be encrypted and hence is not vulnerable to interception, ...
6
In SSL/TLS, messages are sent as part of records. What should be expected is that the client first send a ClientHello message which itself is contained in one or several records.
Record format is:
record type: 1 byte (0x16 for "records contains some handshake message data")
protocol version: 2 bytes (0x03 0x00 for SSL 3.0, 0x03 0x01 for TLS 1.0, and so on)
...
6
The DNS server does not look at the URL; the DNS server does not know what a URL could be.
The client browser extracts the intended server name from the URL. In a URL like https://www.example.com/foobar.html, the server name is the part after the https:// but before the next /; i.e., www.example.com in this example. The server name is what is sent to the ...
4
A client sends a SSLv2 ClientHello when it is ready to use SSLv2, and it supposes that the server may be an SSLv2-only server. In practice, a given client will always send a SSLv2 ClientHello, or never: the client cannot know what a specific server supports until it has actually talked to it, so it is an all-or-nothing configuration option.
Modern browsers ...
4
This is most likely a PHP LFI (Local File Inclusion) attack. The .php.jpg "photo" actually contains valid PHP code that is then parsed by some other script on your site which is vulnerable to LFI.
The other files you found were dropped post-exploitation after the LFI vulnerability was exploited.
You can post the boy.php.jpg for further analysis. Host it ...
4
Certificates are signed. The signature covers all the certificate contents, including the Key Usage extension. You cannot change anything in the certificate contents, not the smallest bit, without invalidating the signature. So no, you cannot "change" a certificate. Certificates are immutable by construction.
Your certificate vendor might accept to give ...
4
CRAM-MD5 requires that the server knows the actual password, not just some image of the password by a hash function. So if the server has to support HMAC-MD5, it has to store the password in plaintext. (The server can encrypt the password, but since it also has to know the encryption key, that doesn't help.)
CRAM-MD5 was designed to avoid having the ...
3
Firstly, it's not necessary to use plaintext:
Looking at the HMAC-MD5 implementation in psuedocode:
you can at least store a modified version of the password:
if (length(key) > blocksize) then
key = hash(key) // keys longer than blocksize are shortened
end if
if (length(key) < blocksize) then
key = key ∥ [0x00 * ...
3
The typical way of defining validity is a series of checks - sometimes later checks are skipped, if the risk of not doing them is deemed sufficiently low.
There is a proof that the sender has control of the private key - in an SSL transaction, this is handled for you as part of the handshake.
Certificate is constructed and signed properly - has a valid
...
3
With such a certificate, any system who trusts your internal CA will trust a server running on "localhost" as being genuine, i.e. running really on "localhost". But "localhost" can be reached, network wise, only locally, so if your client successfully connects to https://localhost/whatever then it already knows that it is talking with the local machine. ...
3
If you can "expose the premaster secret", though the key exchange uses ephemeral Diffie-Hellman, then you have privileged access to either the client or the server. That's one of the points of DHE: the actual key exchange uses newly generated DH key pairs, which neither client or server stores anywhere except in its own RAM. Having a copy of the permanent ...
2
When you connect to an HTTPS Web site which uses a "problematic certificate" (e.g. one which is not issued by a recognized CA, an expired certificate, or a certificate which does not contain the server name as it appears in the URL), the browser asks for confirmation from the user. This can happen only after the server certificate has been retrieved, as part ...
2
An attacker who can modify TLS record headers can actually block packets altogether, thus making the receiver wait "indefinitely". There's nothing that the TLS protocol can do to prevent that.
TLS implementations can use time-out strategies, i.e. if no activity has been received from the peer for some time (e.g. 15 seconds) then the connection can be ...
2
There's almost no threat at all. Do you trust your own computer not to attempt an MITM attack against you? Then there ought to be no problem.
When you try to access localhost, the network adapter isn't even touched. If someone stole the key, the could use it to convince their own computer that it is itself. Or any computer that they have access to (if they ...
2
I don't see any more significant threat for localhost than any other certificate. The main abuse of an SSL cert is to convince a system that you are the system they want to talk to when you are not, but an attacker couldn't compromise the traffic going to localhost unless the client computer is already compromised at a fairly low level (at least has access ...
2
Depends. In general, no. If the attacker launches a man-in-the-middle attack after HTTPS communication has already started, he can do nothing.
If he launches the attack beforehand, he can do various things. For convenience, let's assume that the server in question is GMail.
Pretend to be mail.google.com: This is a pretty transparent attack. The attacker ...
2
Whether the SSL session identifier is made accessible, by your SSL hardware, to the rest of the server, is entirely up to the interface that this hardware offers.
A decent SSL hardware box should offer some kind of session management, so that the consumer (your Apache / nginx / whatever server behind the box) may know whether successive connections are from ...
2
The client won't send a certificate unless the server asks for it with a Certificate Request message (see the standard, section 7.4.4). If the server does not ask for a certificate, the sending of a Certificate and a CertificateVerify message from the client is likely to imply an immediate termination from the server (with an unexpected_message alert). The ...
2
Does anybody know if it is possible to perform an authentication via
client cert if the server does not request it?
No. If a client certificate is not been requested by the server and the client attempts to send it anyway it's very likely that the server will simply abort the connection attempt since it doesn't match the expected reply.
And if it ...
2
The server certificate is sent by the server, to be validated by the client. The client certificate is sent by the client, to be validated by the server. They live in different worlds and have no need whatsoever to relate to the same certificate authority.
For client certificate validation with Apache, see this documentation. The server will need to ...
2
It gives no protection against MITM since an attacker could forward the challenge to the client. Requiring plaintext password storage is bad and the exchange can have have a dictionary attack run against it.
You are justified in being worried about this scheme and I'd personally suggest using a different e-mail provider.
1
There are three relevant weaknesses in this case:
Improper password storage: If your provider's database is compromised, your password is directly exposed. Although some implementations of CRAM-MD5 don't store passwords in plaintext, the hashed password is still unstaled. So far there's no known implementation that salts the password (the salt needs to be ...
1
First off, the plaintext bit is bullshit - most POP/SMTP *nix solutions can be retrofitted to not need this. With this out of the way...
...CRAM-MD5 has shocking vulnerabilities - coming from its MD5 tie. However, it's still better than plaintext. In order of appearance and "OMGWTFBBQ-ness":
A server using CRAM-MD5 can be spoofed/MitM-ed as the client ...
1
Try using Fiddler2. It is free and has a built in HTTPS stripping proxy for exactly the kind of thing you are trying to do. The one trick is that the application will know that the certificate doesn't match so it may or may not complain, but something like Fiddler2 is your best bet at trying to see what's on the HTTPS connection. (You may also be able to ...
1
Tom your answer is so much detailed and useful . I am very thankful . I considered points and tried to improve my implementation. Because it is a little big I am writing as a new answer . It became a little long I don't expect anyone to analyze but if maybe someone needs , it can be useful .
if (flow_special_packet_counter == 0)
{
//SSLv2 no server name ...
1
Not just from certificate but also from handshake messages servername information can be get.
As I tested %80 of the traffic contains server_name extension in client hello message(first message send by client to server in https protocol) . But this extension is optional and sometimes it does not exist .In this case certificate can be checked. In certificate ...
1
From a strict cryptographic point of view, they both provide authenticated encryption, but in two different ways.
SSH uses the so-called Encrypt-and-MAC, that is the ciphered message is juxtaposed to a message authentication code (MAC) of the clear message to add integrity. This is not proven to be always fully secure (even if in practical cases it should ...
Only top voted, non community-wiki answers of a minimum length are eligible
