Tag Info

New answers tagged

1

TL;DR yes it is safe provided that you trust the means by which you came across the value stored in PUB_KEY. Here is some background that is needed to first understand the purpose of pinning, and why your scenario allows for ignoring of the error. I'll concentrate specifically on PKI in an ideal implementation. A private key is a very, very large number ...


2

A trusted root is only relevant if you need to validate the trust chain of the certificate until you get the root. If you only expect a specific certificate or public key there is no need to check any chains and in lots of cases there is no trust chain anyways (i.e. self-signed certificates). In case of revocation you might actually add an URL to the ...


1

If you believe what Google claims here, SSL traffic is not proxied: Is my secure traffic optimized by the compression proxy? No, data compression proxy operates on non-encrypted traffic: HTTPS requests are sent directly from the mobile device to the destination server. That said, I've not hooked up a debugging proxy to snoop the network traffic, ...


2

Chrome 42 has now been released, and I can answer my own question: yes, they must have slowed down. 42 has the behavior that was expected in 41. I'm still not aware of any official explanation or acknowledgement of the delay.


1

I figured it out! The SSL handshake was failing on my (client) side because the client certificate did not have the right permissions for the account that was running the web application. I was able to find this out by looking in 'Windows Event Viewer' under 'Windows Logs --> System'. There I saw an error stating: "A fatal error occurred when attempting to ...


0

I found this post where someone had received the same error phrase "The request was aborted: Could not create SSL/TLS secure channel." (although i reckon this as a very generic description). It says that you need to install the client certificate in the local computer store. Did you do that? If not, how does it work out for you?


0

I've found the answer for this in another post: Why is 'avast! Web/Mail Shield Root' listed as CA for google.com? The problem was that my Antivirus that was creating it's certificate (not that secure, but irrelevant because it's between Avast and the Browser only) and making chrome say that. Everything is fine with the certificate. Thanks for ...


2

HTTP is an inherently "trusting" protocol: it contains little or no built-in security. This means that it is susceptible to the following: Traffic monitoring Anything transmitted over HTTP can be intercepted and read by anyone connected to any network sitting between the source device and the target server. Traffic redirection and manipulation With little ...


0

In addition to what some of the answerers pointed out, most secure sites (e.g. banking web site, etc.), will not even allow you to access secure content through their sites via http. So, using http is not even an option with these sites - you have to use https.


-3

Your website is secured with the SHA-1 algorithm. The SHA-1 algorithm is now outdated and Google Chrome & other web browsers have already quit their support for it. The lower hash value and key length lets hackers crack the website easily. Chrome 38.x users see the website as secured without any warning message, but Chrome 39, 41, 42, .... users will ...


1

Apart from the technological hurdles of getting a tap on the intercontinental lines that could actually read the data, the scenario you provided is indeed possible. If you use HTTP instead of HTTPS your data is travelling as clear text from end-to-end, so your ISP, anyone inbetween and the ISP of your destination host can read or even modify your data if ...


5

You don't need to get another new certificate. In order to resolve this issue, you need to just reissue your certificate with SHA-2 signature. That's it.


12

Google blogged about flagging Certificates using SHA-1 here -> Gradually sunsetting SHA-1 There's no reason to get a new certificate yet as Chrome won't be actually blocking the certificate just treated as “secure, but with minor errors”, I believe that some issuers are offering to reissue certificate but as always, YMMV.


0

You can sniff HTTP Packets using Tools like Wireshark and its like a walk in the park to read your data Packets.An attacker can Intercept your Data Packets modify it and forward it. eg:You ask your bank to pay you - Attacker modify this packet and ask the Bank to Pay Him. I dont understand what you mean by HTTP in your WIFI Network.Dont you want to access ...


1

I found a solution as I was looking for; http://blog.engelke.com/2015/03/03/creating-x-509-certificates-with-web-crypto-and-pkijs/ But I'll try pem modulus at first. Because it works on back-end and seems more simple.


0

"Secure enough" and "trusted" are risky phrases. If you're talking about transmitting a credit card number, email address, SSN, or other personal information unencrypted as plain text via a URL parameter then this is definitely unsecure, regardless of where it is going. The page would need to be an encrypted page for that information to be encrypted in ...


1

Such a setup can be trusted, since the payment details cannot be extracted by your hacker and the payment details can be verified securely. The thing to watch out for is that a lot of user might not bother to double-check the details on the https page, or if there are 'hidden' paramaters sent along that aren't displayed and verified explicitly.


2

This would have been better here. However we can still answer your question. I inspected the site you referred to and the reason, why chrome shows you a security warning is because the intermediate certificate of StartSSL uses SHA-1 for signature-hashing. Your certificate is in fact SHA-256/RSA-4096 as claimed, but because one certificate in the chain (the ...


1

The two would be equally secure assuming you do things right (TLS certificate pinning on one side, and client cert authentication), but I'd prefer the VPN as it's easier to use in the long run. HTTPS isn't that easy to use - each HTTPS server should have a cert, the app accessing the API endpoints should take care of verifying the authenticity of the remote ...


4

Strictly speaking, no, mutual authentication does not protect against POODLE. Some details may matter, though. The core of the POODLE attack is that there is a way, with SSL 3.0, to alter some records so that the receiving end will not notice the substitution with probability 1/256. With this protocol misfeature, attackers can "try" decryption guesses on a ...


3

Terry Chia answered the question "What is the benefit of rotating certificates so frequently?" fully correct, so there's nothing for me to add. However, I'd like to add a note that Google does frequently change their public keys as well, so the assumption of the cheat sheet is invalid. This does add pretty much confusion and may be part of the reason for ...


1

RFC 5280, Section 4.1.2.5 ("Validity") does answer your question technically exactly. In short, a certificate with an expiry date of 99991231235959Z (23:59 GMT on 31st of December 9999) does serve your exact requirements, but RFC 5280 also requires that you must be able to revoke that certificate in order to break the certification path (i.e. by revoking ...


30

One big advantage is removing the need for revocation in the event of a compromise. The "typical" way to do this is publishing a certificate revocation list (CRL) or using the OSCP protocol in the event of a compromise to revoke certificates. However, the CRL or OSCP check is incredibly easy to bypass. An attacker in a position to perform a MITM attack can ...


-1

I want to produce a signal such that when a cell phone enters that area, I must get all the specifications of that device. That's not how cell phone signals work. Can I do it? Nope. Which signal is good? I don't think this question has a correct answer.


1

First, enable SSL debugging on the client by setting the javax.net.debug system property from the command line (-Djavax.net.debug=all) or in runtime. Stdout will have quite detailed logging of the SSL connections, as long as you are using the build in SSL provider. More details at: http://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/ReadDebug.html ...


1

I've read the history of the work on this part of the TLS specification. Eric Rescorla (co-editor of TLS 1.1, 1.2 and 1.3) posted on Dec 31st, 2007 on IETF TLS working group mailing list about a work item called "Issue 66: HMAC-256 based ciphersuites" for the next draft of TLS 1.2 (then called RFC4346-bis, i.e. a revision of TLS 1.1, now known as RFC 5246). ...


0

A good general tool to use when testing and learning about pen-testing is Kali Linux. It comes with both test targets and tools. You can use VirtualBox to host it on an existing machine if you don't have another machine to use.


0

The thing you want to guarantee here is freshness, so having the client sign some nonce - any nonce, as long as it's fresh - will work. Ideally, that signature should also be bound to the channel, but the signature and nonce are being transmitted inside the encrypted channel, so maybe that's enough. Ideally, though, you're right, signing the TLS shared ...


2

They are doing a man-in-the-middle attack which needs the user to either ignore security warnings or to explicit import the CA used by fiddler. For more discussion about this topic have a look at How can I prevent a man-in-the-middle (MITM) attack on my Android app API?


2

The reason you're getting this is because you load certain resources over HTTP. When you look at the page source code, you'll see this: <link rel='stylesheet' id='google-font-body-css' href='http://fonts.googleapis.com/css?family=Open+Sans+Condensed&#038;ver=4.1.1' type='text/css' media='all' /> <link rel='stylesheet' ...


2

There are two chains up to Verisign Class 3 G5. At one point, Verisign was chaining to that root via a longer chain, and some OSes were confused when walking up the AIA versus walking up the chain handed by the server to the client. This sounds like a significant problem, especially since the combined Symantec properties are the largest tier 1 CAs. I do ...


13

Solved. The problem was indeed triggered by installing Apple Mavericks/ML Security Update 2015-004. As mentioned in this Apple release note, it included updates to the certificate trust policy. There was a duplicate certificate installed (with a wrong serial no.), removing it fixed the problem. The serial number for the cert as published by Apple matched ...


3

To give the good answer from thexacre a broader touch: If the application itself does the certificate checking correctly (not all do, see http://www.kb.cert.org/vuls/id/582497) then an MITM attack is only possible if the attacker is somehow trusted by the owner of the device. In case of an owner which is curious what the application does the attacker is the ...


18

That app (and all MITM proxy apps such as SandroProxy and mitmproxy) work by installing their own trusted CA certificate on the device. That allows them to sign their own certificates which the device will accept. You have to manually install their certificate to the user key-store using a dialogue such as this: After which it displays warnings such as ...


3

Yes, and no. Using client certificates doesn't solve the problem, it moves the problem. Whereas before your problem is the creation, distribution, and protection of a password or other secret. And now your problem is the creation, distribution, and protection of a client certificate. A client certificate is a lot like a password. But it has the special ...


0

You can use an encryption algorithm like RC4 or AES. You can encrypt the auto generated password in your app with a key and decrypt the same at server before account creation. If any user catches the transfer he will only see some random sequence of letters. If your users have an account on your server than you can also generate a unique encryption key for a ...


3

The two keys you show are encoded differently - obviously, the first is base64 encoded, and the second is hexadecimal encoding. You would need to determine the formats used and their encoding to determine how to reconcile the two. And in both cases it's a packed structure, not just raw key data but discrete bits of data like key type, exponent, and ...


3

From your description at this query at stackoverflow I get the information, that all customers will use their browsers to contact these sellers. When you only use self-signed certificates or use your own CA for the sellers each of these customers must explicitly add an exception (or your CA) to their browser. And of course they should not just trust ...


2

When the https portion of the URL in Chrome has a red line through it, there is a problem with the security of the site you are going to. To see exactly what the problem is, you need to click on the padlock and see the detailed connection info. Detailed connection info is documented here. If you see , then you've established a secure connection with a ...


2

Data are sent within TLS in records and the MAC is computed over the contents of the record, see http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_record. The size of the record is independent of any packet sizes of the underlying transport layer, that is a packet can contain multiple records or a record can also span multiple packets. The record ...


0

You're referring to when web browsers draw a red line through the "https://" in their URL bars. It means that the browser does not trust the certificate that the site is using, for many possible reasons: it isn't signed by one of the root CA certificates that the browser implicitly trusts it's signed by a root CA certificate that the browser used to ...


2

It should be noted that there's nothing wrong with the certificates from a TLS or x509 point of view. The CA/Browser forum applies to CAs issuing publicly-trusted certificates that subscribe to those guidelines. Not all TLS or x509 use cases involve public trust. An internal government or enterprise CA, for example, might reasonably choose to completely ...


0

Updated to better explain what's going on after referencing the original paper. Since it's block encryption and the attacker is tricking the user into sending requests, the attacker can force the requests to 1) have a full block of padding and 2) have a block where a specific byte of the secret cookie is at the end. Since the block cipher decryption is the ...


0

However, I would have to make sure that Firefox actually checks the validity of the certificate, or am I wrong? Does Firefox do that? If you add an exception for a certificate to Firefox it will only associate the exception with the hostname in the URL. If you then get the same certificate with another hostname you must add the exception again. If ...


0

It sounds like you haven't included a subjectAltName section in your self-signed certificate, listing all the domain names and IP addresses under which you'll access the NAS device. Even though Firefox has been told to disregard that this certificate has no trusted issuer, it still can't confirm that the URL you're using is covered by your security ...


0

So after a bit of digging I came across a commit on GitHub that can do this. I uncommented virtual_server = check-eap-tls in eap.conf Then create check-eap-tls in sites-available and symlinked it to sites-enabled: server check-eap-tls { authorize { if ("%{TLS-Client-Cert-Common-Name}" =~ /^[A-z.]*@example\.com$/) { update config { ...


1

First to answer your original question: How can RSA be used for digital signing and encrypting and DSA only for encrypting? To understand this one has to dig into the definitions of RSA and DSA. RSA by itself was designed to be a public-key encryption scheme and later converted to a digital signature scheme. RSA does encrypt data by rasing them to an ...


2

As described in this answer and in this commit to chrome only AEAD ciphers are considered state of the art security. It looks like that your server does not use the cipher preference of the client but instead has their own preference which looks like this: ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA ... ...


-1

It is actually the usage of a SHA-1-signed certificate. Everybody (including Google and Mozilla) is phasing them out. Edit: Open that address in a new tab and take a look at the browser's console. There should be a link that will give a better explanation about what the issue really is.


1

Would the target URL be aware that multiple SSL Interceptions have happened? In theory the target URL is not aware of SSL interception at all, no matter how many SSL interceptions you do. It only sees that it is doing the SSL handshake with some kind of client and can not see if it is doing the handshake directly with the browser or with some SSL ...



Top 50 recent answers are included