Exam CAS-004 All Questions

View all questions & answers for the CAS-004 exam

Exam CAS-004 topic 1 question 24 discussion

Actual exam question from CompTIA's CAS-004

Question #: 24
Topic #: 1

A customer reports being unable to connect to a website at www.test.com to consume services. The customer notices the web application has the following published cipher suite:

Which of the following is the MOST likely cause of the customer's inability to connect?

A. Weak ciphers are being used.
B. The public key should be using ECDSA.
C. The default should be on port 80.
D. The server name should be test.com.

Show Suggested Answer

Suggested Answer: A 🗳️

by snilu at April 21, 2022, 12:57 a.m.

Comments

Submit Cancel

snilu

Highly Voted 3 years, 2 months ago

A) "SHA-256 is not a secure password hashing algorithm" ECDSA is not mentioned.

upvoted 11 times

...

BiteSize

Highly Voted 1 year, 11 months ago

Selected Answer: A

https://ciphersuite.info/cs/TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/ has quite a few weaknesses. when looking up ECDSA and connection issues, it says that the cipher suite of ECDSA is TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 So because the published application suite that the user is trying to connect to is stating RSA cipher, it's probable that it's because it is weak. RSA cipher suites don't work without a RSA Public key. https://serverfault.com/questions/1050808/tls-1-2-with-rsa-vs-ecdsa-ciphers

upvoted 7 times

BiteSize

1 year, 11 months ago

Also, due to "The decision on which cipher suite will be used depends on the web server. The agreed cipher suite is a combination of: Key exchange algorithms, such as RSA, DH, ECDH, DHE, ECDHE, or PSK Authentication/Digital Signature Algorithm, like RSA, ECDSA, or DSA Bulk encryption algorithms, like AES, CHACHA20, Camellia, or ARIA Message Authentication Code algorithms, such as SHA-256, and POLY1305" https://www.keyfactor.com/blog/cipher-suites-explained/ Source: Verifying each answer against Chat GPT, my experience, other test banks, a written book, and weighing in the discussion from all users to create a 100% accurate guide for myself before I take the exam. (It isn't easy because of the time needed, but it is doing my diligence)

upvoted 2 times

...

So_fly58

Most Recent 1 month ago

Selected Answer: B

Explanation: The customer is unable to connect to the website, and the cipher suite and key exchange details provide a strong clue. Here's a breakdown: Cipher Suites in Use: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 These use: ECDHE for key exchange (Elliptic Curve Diffie-Hellman Ephemeral) RSA for authentication AES-CBC for encryption SHA-256/384 for hashing Public Key: RSA (2048 bits) This setup is technically valid, but some modern clients (especially mobile or newer browsers) prefer or require ECDSA (Elliptic Curve Digital Signature Algorithm) for performance and security reasons. If the client does not support RSA-based authentication or if the server does not offer ECDSA-based cipher suites, the handshake may fail.

upvoted 1 times

...

blacksheep6r

4 months, 2 weeks ago

Selected Answer: D

Key Takeaway: 💡 DNS configuration and ServerName mismatches are common causes of web connectivity issues. If the server is set to www.test.com only, users accessing test.com without www may fail to connect. D) The server name should be test.com. ✅ Correct! The configuration specifies ServerName www.test.com, meaning it expects requests to come to www.test.com specifically. If the customer is trying to access test.com without www, the server might not properly respond to the request. Fix: The server should either support both test.com and www.test.com or set up a proper redirect.

upvoted 1 times

...

blacksheep6r

4 months, 2 weeks ago

Selected Answer: D

A) Weak ciphers are being used. ❌ Incorrect The ciphers listed are strong and secure (AES-256-CBC, AES-128-CBC, and ECDHE for perfect forward secrecy). If weak ciphers were an issue, the problem would be with security compliance, not connectivity. D) The server name should be test.com. ✅ Correct! The configuration specifies ServerName www.test.com, meaning it expects requests to come to www.test.com specifically. If the customer is trying to access test.com without www, the server might not properly respond to the request. Fix: The server should either support both test.com and www.test.com or set up a proper redirect.

upvoted 2 times

...

grelaman

8 months, 1 week ago

Selected Answer: C

• The <VirtualHost *:80> directive correctly listens on port 80 (HTTP) and redirects traffic to https://www.test.com. • Using <VirtualHost _default_:443> means that this virtual host will only catch HTTPS requests that don't match any other virtual host on port 443 . Since it's set as the default, Apache might not correctly match the ServerName www.test.com when handling SSL/TLS connections. The use of <VirtualHost _default_:443> can prevent Apache from correctly matching the ServerName for SSL/TLS connections, causing clients to be unable to connect to https://www.test.com. SOLUTION: - The <VirtualHost _default_:80> directive sets the default virtual host for all HTTP traffic that doesn't match any other virtual host on port 80. - The <VirtualHost *:443> tells Apache to listen on all IP addresses for port 443 and properly match the ServerName directive (which is www.test.com in your case).

upvoted 2 times

grelaman

8 months, 1 week ago

EXAMPLE: 1. The user enters http://www.test.com into their web browser and presses Enter. 2. This initiates an HTTP request to www.test.com on port 80, which is the default port for HTTP traffic. 3. Since the request is for http://www.test.com on port 80, Apache looks for a <VirtualHost> block that matches this configuration. The <VirtualHost _default_:80> block is configured to handle all HTTP requests that don't specifically match another <VirtualHost> on port 80. In this case, since there's only one VirtualHost for port 80, it matches the incoming request for www.test.com. the directive Redirect / https://www.test.com tells Apache to redirect any request it receives to the specified HTTPS URL. 4. Upon receiving the redirect response, the user's browser automatically navigates to https://www.test.com. This means the user is seamlessly taken from the unsecured HTTP version of the site to the secured HTTPS version.

upvoted 2 times

...

23169fd

11 months, 2 weeks ago

Selected Answer: B

B is correct. A: These are are strong ciphers and are generally considered secure. C:The configuration correctly redirects HTTP traffic (port 80) to HTTPS (port 443), which is standard practice. D:The server name configuration www.test.com matches the standard expected URL format

upvoted 2 times

...

Delab202

1 year, 5 months ago

Selected Answer: B

Based on the provided information, the MOST likely cause of the customer's inability to connect is: B. The public key should be using ECDSA.

upvoted 1 times

...

llamaPaja

1 year, 11 months ago

I'd guess A - read this: https://ciphersuite.info/cs/TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/ It is clear, that CBC is not recommended for use for a long time...

upvoted 5 times

...

FOURDUE

2 years, 4 months ago

Selected Answer: A

https://community.progress.com/s/article/unable-to-connect-to-site-externally-weak-cipher-or-http2-error

upvoted 4 times

...

angryelvis

2 years, 6 months ago

Selected Answer: B

OK, we all agree that this is a weak cipher suite (see the link below). But, that's not the question. The question is about the "inability to connect". Look at the below link and you will see that ECDSA is used to authenticate. You can connect to a weak cipher suite but if you're missing the signature algorithm... https://ciphersuite.info/cs/TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384/

upvoted 6 times

...

kycugu

2 years, 6 months ago

In practice, a RSA key will work everywhere. ECDSA support is newer, so some old client or server may have trouble with ECDSA keys. I will go for "A" reference: https://security.stackexchange.com/questions/23383/ssh-key-type-rsa-dsa-ecdsa-are-there-easy-answers-for-which-to-choose-when

upvoted 3 times

...

lordguck

2 years, 6 months ago

I go for A: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 is labled a weak on ciphersuite.info

upvoted 4 times

...

Andre876

2 years, 7 months ago

The answer is A. https://ciphersuite.info/search/?q=TLS_RSA_WITH_AES_256_CBC_SHA256

upvoted 2 times

...

Sloananne

2 years, 9 months ago

Selected Answer: A

A) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 and TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 are both considered weak cipher suites. May be vuln to BEAST attack since they are 1.2 TLS

upvoted 2 times

...

dangerelchulo

2 years, 9 months ago

Selected Answer: A

C and D are not valid answers. for why C is not a valid answer check this link on how to handle https redirect https://stackoverflow.com/questions/13376219/htaccess-redirect-http-to-https Leaning towards A since is similar behavior as cipher mismatch. cipher used is TLS 1.2 and client might be using TLS 1.3 connection. Again CompTIA doing its miss direction.

upvoted 2 times

ito4862

2 years, 6 months ago

From the link you sent, I followed it to https://cwiki.apache.org/confluence/display/httpd/RedirectSSL. Wouldn't this prove that D is the answer? NameVirtualHost *:80 <VirtualHost *:80> ServerName www.example.com Redirect / https://secure.example.com/ </VirtualHost> <VirtualHost _default_:443> ServerName secure.example.com DocumentRoot /usr/local/apache2/htdocs SSLEngine On # etc... </VirtualHost>

upvoted 1 times

ito4862

2 years, 6 months ago

Nvm, I believe A is the answer. I remembered that I have used old government websites that needed to have TLS 1.0 enabled in order to connect. I specifically had to go into IE settings and enable them for the website to work.

upvoted 2 times

...

dangerelchulo

2 years, 9 months ago

C can't be the answer since port 80 is plain text communication while 443 is the cipher communication. Website is set to default to port 443 so i can successfully communicate in the cipher stated above.

upvoted 3 times

...

Load full discussion...