Steffen Ullrich

@12characters: " I think I can solve that by sending a secret with every call from the phone app and the computer app just allows requests with that particular secret. " - an active man in the middle with its own certificate can read the plain traffic including the secret. It can then simply pass on the traffic including the secret to the real server, but then change the file which got transferred by the server to the client, like sending malware instead.

@12characters: so your thread model is an attacker which can only passively sniff to the network but not do active man in the middle, i.e. no IP or ARP spoofing possible in your network?

@12characters: The point of an encrypted and authentication connection is to protect against some attacker which might hijack the connection. You basically assume that no such hacker exists in your case. In this case - what exactly do you want to protect from?

@12characters: Verifying the identity (IP address) is not sufficient to validate the certificate. The point of a certificate is to prevent spoofing an identity by having some additional trust anchor. Typically this trust anchor is the issuer of the certificate, which need to be trusted already by the client. But, with a self-signed certificate this already trusted anchor does not exist, because the issuer is the certificate itself. In other words: an attacker could simply create its own self-signed certificate for the same IP address and thus impersonate/MITM the real server.

"self-signed SSL certificate that is generated each time the app is started" - if you generate a new self-signed certificate on each start, then on what base can the peer verify the trust in the certificate?

@Delfin I've shown several options. Only looks these were not what you expected to hear. They are still not wrong. If your conclusion based on this is "nothing is possible", then this is a conclusion based on your personal preferences and restrictions.

But, this is only about authentication, not about encryption. Your question is about client-side encryption though. Encryption needs some key to encrypt and thus something to derive the key from. Authentication just needs prove of identity, which can be simpler.

@Delfin They complain about insecure use of password since passwords are insecurely used. If you replace the password with "differently structured secret" but don't change the fundamental problem of insecure use, then they will complain about this new thing. The current movement for killing password is more focused on providing something which is both more secure and easier to use, i.e. Webauthn, biometry, ....

@Delfin storing a password in a password manager or storing some "differently structured secret" in the password manager is also the same from the perspective of security. So why should be one of these acceptable but the other not? Also, how is this password manager then protected?

@Delfin And how exactly is this different from writing down a password? I don't see any difference in security between writing down a password and writing down some "other structured" secret.

@Delfin This is what I consider "stored on a specific device" - which you explicitly excluded. Maybe we understand different things behind this term.

@Delfin ok, in this case: you can have an algorithm with parameters. The algorithms is fixed, the parameters need to be remembered. The structure is different from a password but it does not help much in my opinion, i.e. the problem is the same as with a password in that it needs to be easy to remember but hard to guess. Or it needs to be some "hardware" which contains part of the data, like a book. But you don't want such hardware if I remember correctly.

What is the difference to a "password" then, apart from not calling it this way?

@Delfin: And how do you think these challenges should work without the user either remembering something (which is needed to solve the challenge) or the user having some device which does this? Also, the server should never get access to the secret or something which can be used to get the secret, so how should the server ask useful challenges to derive the right secret?

@Delfin: a) you need to have some encryption key b) it needs to come from somewhere. Basically you have in impossible restriction for b) in that it should not be locally stored, not remotely stored, not derived from something stored locally, remotely, on a device, in the brain of the user .... This is impossible.

@Delfin: extended the answer. In short: if it should not be stored locally it must be stored remotely and then retrieved in a secure way.

Also, if you want to know about browser level trust you should test with the relevant browsers. For example Firefox comes with its own trust store. In general, using self-signed certificates or running your own CA is not a good idea if you want to serve many customers and different client applications. It does not really scale and supporting it will be a hassle

See apple.stackexchange.com/questions/371725/… for the requirements in iOS. Note also that you specified a validation period of 365 days for the CA but 825 days for the certificate issued by the CA. This makes no sense, the expiration of the certificate should not exceed the expiration of the issuing CA

@David: It is not about weaker vs. stronger conditions. There is simply not a single trust store which is used by all applications. You might need to make adjustments for each application which trust store to use. For requests you can use the verify argument to specify what CA to trust. This is also not specific to MacOS but same mess on Windows and to some extend on Linux too.

You must not use the same subject for CA certificate and server certificate. This is not specific to MacOS. Apart from this change (i.e. replace CN=special-name with CN=CA) for the CA it works for me on MacOS when testing the generated server certificate with openssl s_server and using curl --cacert ... as client.

@David: I don't think curl on MacOS will use the system CA store. Use --cacert argument instead to specify your CA.

You only describe how you generate the certificates but not how you actually use these. How did you import these into the trust store, how did you check if it works, what exact errors you get ...

It is very unlikely that independent providers use some custom protocol unlike SMTP to deliver mail between each others. Also, SMTP can already be used to achieve end-to-end security between providers, so no need to invent something else to get this security property.

@Arkhan6: "Can the attackers enter Telegram servers?" - They likely have some kind of protection against attacks by malicious clients - but this kind protection is not achieved by transport encryption. "I am sure that a lot of people have their computer infected with malware." - I agree with this statement but I don't agree with your conclusion that these users will be "somehow" protected from the attacker. Security is neither achieved by magic nor by wishful thinking. And a compromised system with an authenticated Telegram account on it should be considered a compromised Telegram account.

@Arkhan6: "If the malware steal de public key ..." - a public key does not provide any protection by itself and needs not to be protected against "stealing" - it's "public" (hence the name). It is used in connection with the private key (secret to the server) to prove the server authenticity and to prevent man in the middle attacks. An attacker on the clients system is not a man in the middle - it is a man in the client instead which is not protected against.

@Arkhan6: You have two issues here: 1. protect the communication with the servers against someone in the communication path. This can be done with VPN, SSH tunnel, TLS ... . 2. make sure that the client which talks to the server isn't malicious: this cannot be solved by some kind of tunnel, TLS ... . browsers, Telegram, ... only care about (1) and simply assume that the client device is not compromised (2). How much do you trust your employees to keep their system sufficiently safe?

@Arkhan6: This will not protect against a compromised personal device either. If you do online banking through a browser they also expect you to use a secured device since they cannot ensure security of the banking if your device is compromised.

@Arkhan6: No kind of VPN, SSH tunnel, TLS ... will make a compromised device secure. These technologies just protect the communication against interception and modification. They don't make sure that only "harmless" communication is done.

@Arkhan6: If you allow your employees to use their own computers to connect to your network you have more problems than stealing the VPN key. First it is likely possible. Second it might not even be necessary because an attacker should just use the compromised personal device of the employee as a jumphost into your network, i.e. make use of the established VPN.

It's a bit more clear what problem you face, but your task in solving it is still unclear. Are your responsible to roll out an external application at your site, with clients and server in your control? Do you only control the server and need to make external clients use it, without having access to their computer, ... something else?

There are too few details and context known here. What do you mean with "connect to the server in a safer way": what kind of communication happens and what to protect it from? Why do you want a network level protection (VPN) to protect a (seemingly?) application communication in the first place instead of using application level protection like TLS?

If the question is this way then I would probably have picked security by design too. But its a terrible question

I really recommend to read the publication I've linked to. I think it is very well written

If it is not secure by default it can be fixed by the customer by applying the proper secure configuration. If it is not secure by design it cannot be fixed by the customer.

@CharlesOwen: "Which of these two principles would be viewed as more secure?" One might say that secure by default is the easier one to achieve while deeply implemented security by design has more impact but takes also much more effort. But at the end both are needed.

@CharlesOwen: I'm not familiar with having a separate CM which only cares how the software is configured and is not integrated with software development. From my perspective implementing how a software gets configured and to ensure that the defaults are secure is a part of software development.

@CharlesOwen: If you mean with CM the configuration management at the customer side then no - the software should come secure by default already without requiring specific customer configuration.

I cannot give any recommendations. I never followed any specific carrier path, but just followed what interested me. There are many different areas in security so just read as much as you can and figure out what fascinates you the most.

But in general - the input (source) is where it comes from - which is your URL parameter for the search. The sink is where it ends up - which is your HTTP header

XSS means cross site scripting - there is no scripting involved here.

This is no XSS

you can try. If it is easy to answer I'll do it here, otherwise it might be better posted as a real question.

Given that it is based on a wrong assumption I would recommend to simply delete it

The Set-cookie in the HTTP body is irrelevant here, what matters is the Set-Cookie in the header. As you can see there is a Set-Cookie in the header in the attempt to preserve the search entered by the user. But due to the search string having a newline inside ("test%0d%0aSet-Cookie ...") and improper input filtering/validation one is able to add another Set-Cookie header with a chosen content. This is also called a HTTP header injection attack.

I have no idea what the actual response (HTTP header and body) from the server was. But a browser will not interpret plainly given HTTP fields inside the HTTP body (as in your example code) as actual HTTP headers. So if the exploit works there need to be something else than this.

The meta tag is inside HTML. An no, a browser will not simply parse the body for HTTP headers.

See Setting a Cookie using only HTML5

of course it is not standard conform to use a different name in the SNI than actually accessed. But there are similar obfuscation concepts both for good reasons (privacy) and bad (evading detection by malware) - see for example domain fronting

not fully clear what is going on here. But it might be that this is the obfuscation done by vray which is resulting in this output

Too few known what the contents of these packets is and how they relate to the other packets.