@SteffenUllrich The user himself types in the IP address of the other machine (the IP address is displayed in the app) so that both apps can connect. So the trust is verified through the user (in my logic).

@12characters Can you trust IP's?

@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.

@SteffenUllrich Sorry, I can't follow. The user/app connects to the IP address of his own device. No communication with other IP addresses exists. So there is no connection made to the attackers IP?

@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?

@SteffenUllrich I assume that there might be an attacker which listens to the network traffic. I think this is the most realistic or most common case and therefore I want protection.

@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?

"everyone in every network should be able to use the apps" - that would include the attacker using your apps, right?

I'm unclear about which application is going to present this certificate. Typically, the host (your http server) presents a certificate. That's sufficient for encrypting the traffic coming from any client. I'm not sure but it seems like maybe you are thinking the client will generating a new certificate. Please clarify.

there's no need for HTTP here. Just secure the LAN and that's it. There are various ways to share files over the LAN without HTTP. If you want to create an HTTP "intranet" just be sure there is no way to connect outside of the network. If you have domain-level authentication in place, also be aware of CSRF. (if you're really paranoid and think a machine-name could be leaked/guessed, or if a local client uses localhost for some odd reason) HTTPS on intranet is to mitigate against insider threats. A user in the LAN spying on another user in the LAN.

@SteffenUllrich I didn't know IP spoofing existed. But 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. I think I can't do anything if the attacker is the first one to connect to the computer.

@browsermator I am worried about public hotspots. So "A user in the LAN spying on another user in the LAN." is exactly my case.

@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.

"I am worried about public hotspots." You can't access your LAN via public hotspot. If your requirement is to provide internet access to your computers on a LAN, that's a whole different ball of wax.

@SteffenUllrich Sorry for my questions, but I am new to this topic: I don't yet understand how someone could do a mitm attack in this particular case.

@browsermator I meant transferring files via the applications in a public wifi.

hmm... define "public". It really sounds like you've got LAN (local network) mixed up with something else, but not real sure.

@browsermator like McDonalds free wifi. Everybody can get in there, mostly without a password

OK, I think you're saying you need access from outside of the LAN. (from the internet not from inside the LAN) That's different than "transfer files between a computer and a cell phone in the same network". Same network is now irrelevant. You'll need user accounts and https or a secure FTP server. (or use some 3rd party service like Google drive)

@browsermator No. I don't need the internet. The only communication I have is between two devices in the same LAN. I am worried about attackers in this said LAN, who e.g. listen to the traffic in the said LAN. No internet. No outside of the LAN.

secure the LAN. You can serve http without exposing that traffic to the internet at all. No one from McDonalds should be able to access your local network.... if that happens now, you've got some serious holes to plug up. You have a lot of options for local network file transfers. Http is probably not what you want but you can do that if you like.

I think you're thinking that setting up a server would mean you have a global, internet accessible, IP address. If you setup an intranet, you'll be using either the machine name or a local IP address for the URL.