New answers tagged ssl
1
Bundling certs, installing embedded certs, implementations DO NOT MATTER period. If you think this is the case, you're missing the underlying handling of certificates.
When a connection is made via the PKI infrastructure it usually works as follows:
Client (with cert) --> before connection is made, let me consult CA --> Internet
Client (with cert) ...
1
Actually, depending on how your client implements SSL/TLS and PKI, it might be possible for an attacker to pull off something vaguely similar: For instance, read this page on how eavesdropping on secure connections might be technically possible, if sufficient attention isn't paid to the PKI part of SSL/TLS.
For short: The attacker would generate a root ...
8
It is not the certificate which matters, but the private key. That one does not leave the server. To impersonate the server, the man in the middle would need to obtain that private key. The certificate itself is public data, and sent by the server to every client who asks for it by simply connecting.
(A Man in the Middle attack is a double impersonation: ...
6
Blocking TOR at a network level is difficult, and anyone trying to do so will face a constant battle with the TOR developers. It's similar to the red queen effect between malware developers and AV researchers; every time an improved technique comes out to block TOR the developers will change the way it works.
I see TOR use as more of an endpoint control ...
5
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 ...
1
It might depend a bit on the certificate vendor's policy, but usually changes in the certificate require you to buy a new one.
7
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
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 ...
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
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
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 ...
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 ...
3
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 ...
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 ...
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
...
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 ...
-1
You should definitely inform all the stakeholders of your website who might be in danger if any sensitive data was leaked. Also, you should compare your current code with the original code and do a code reversion to make sure any malfunctions that were inserted are removed. Check your VPN and communicate with the authorized people in your company to be on ...
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 ...
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 ...
1
The first one is grabbing the certificate itself, the second is making a secure handshake, and the last is getting the actual data.
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 ...
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 ...
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 ...
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. ...
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 ...
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, ...
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 ...
0
I think it is just a HSTS implementation to retain SSL certificates of browser clients when a MITM sslstrip attack is made against the web user
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 ...
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 ...
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 ...
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 ...
7
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)
...
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 ...
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 ...
Top 50 recent answers are included
