Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Untrusted SSL #157

Open
532910 opened this issue May 17, 2019 · 6 comments
Open

Untrusted SSL #157

532910 opened this issue May 17, 2019 · 6 comments

Comments

@532910
Copy link

532910 commented May 17, 2019

  1. Clear text traffic is no longer allowed in Android 9.0. Please enable SSL/TLS on the CUPS server/printer. Trying to manually specify printer without ssl will give this error at print time.

image

So it's better to suggest https://server.tld:631/printers/Printer_Name at least on android 9, or even prepend https as a must.

image

  1. Specifying printer via https (or via auto discovery) requires to trust cups certificate.
    image
    image
    This requires three printing attempts before sucessfull printing will be possible.

On the one hand this is correct behaviour, on the other the native Default Print Service in android 9 silently trust this certificate.

@firefinchdev
Copy link
Contributor

Android Pie and above does not allow Clear Text HTTP Traffic by default. Its possible to allow such requests to be made by our app using android:usesCleartextTraffic="true" in manifest.
Reference:
https://stackoverflow.com/questions/51902629/how-to-allow-all-network-connection-types-http-and-https-in-android-9-pie
https://stackoverflow.com/questions/45940861/android-8-cleartext-http-traffic-not-permitted

@n03l
Copy link

n03l commented Oct 25, 2020

Would it be possible to release a new version of the app with this change in?

@wga22
Copy link

wga22 commented Feb 16, 2022

I am still having issue with this. Is it possible to print to an ipaddress or local server without https?

@jbglaw
Copy link

jbglaw commented Dec 28, 2022

I initially only had plain HTTP running and added a HTTPS listening port along with a self-signed cert. (Probably won't get a proper cert for my internal network.) I configured that https:// printer manually, but I still cannot print to it. It becomes "unavailable" after selecting it. It seems that somehow either HTTP is chosen again, or (that'd be my guess) it cannot cope with the self-signed cert: I didn't get any notification whether or not I'd like to accept that. So it's probably considered invalid. Server-side log while selecting the configured printer:

d [28/Dec/2022:21:39:30 +0100] cupsdDeleteCert: Removing certificate for PID 0.
D [28/Dec/2022:21:39:30 +0100] cupsdAddCert: Adding certificate for PID 0
d [28/Dec/2022:21:39:30 +0100] cupsdAddCert: NumSystemGroups=1
D [28/Dec/2022:21:39:30 +0100] Closing client 11 after 300 seconds of inactivity.
D [28/Dec/2022:21:39:30 +0100] [Client 11] Closing connection.
D [28/Dec/2022:21:39:30 +0100] cupsdSetBusyState: newbusy="Not busy", busy="Not busy"
d [28/Dec/2022:21:39:30 +0100] cupsdAddSelect(fd=15, read_cb=0x55ab9aa62d80, write_cb=(nil), data=0x55ab9b16d770)
D [28/Dec/2022:21:39:30 +0100] [Client 11] Waiting for socket close.
d [28/Dec/2022:21:39:30 +0100] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1672259970
d [28/Dec/2022:21:39:30 +0100] select_timeout: JobHistoryUpdate=1672329246
d [28/Dec/2022:21:39:30 +0100] select_timeout(0): 1 seconds to timeout a client connection
d [28/Dec/2022:21:39:30 +0100] [Client 11] cupsdReadClient: error=0, used=0, state=HTTP_STATE_WAITING, data_encoding=HTTP_ENCODING_LENGTH, data_remaining=0, request=(nil)(), file=-1
D [28/Dec/2022:21:39:30 +0100] [Client 11] HTTP_STATE_WAITING Closing for error 32 (Broken pipe)
D [28/Dec/2022:21:39:30 +0100] [Client 11] Closing connection.
D [28/Dec/2022:21:39:30 +0100] cupsdSetBusyState: newbusy="Not busy", busy="Not busy"
d [28/Dec/2022:21:39:30 +0100] cupsdRemoveSelect(fd=15)
d [28/Dec/2022:21:39:30 +0100] cupsdRemoveSelect(fd=-1)

tcpdumping it reveals:

21:44:33.204551 IP 192.168.1.94.33344 > 192.168.1.1.632: Flags [S], seq 1788039088, win 65535, options [mss 1460,sackOK,TS val 326702642 ecr 0,nop,wscale 8], length 0
21:44:33.204703 IP 192.168.1.1.632 > 192.168.1.94.33344: Flags [S.], seq 3784400821, ack 1788039089, win 28960, options [mss 1460,sackOK,TS val 3951610201 ecr 326702642,nop,wscale 7], length 0
21:44:33.208354 IP 192.168.1.94.33344 > 192.168.1.1.632: Flags [.], ack 1, win 343, options [nop,nop,TS val 326702643 ecr 3951610201], length 0
21:44:33.211116 IP 192.168.1.94.33344 > 192.168.1.1.632: Flags [P.], seq 1:257, ack 1, win 343, options [nop,nop,TS val 326702643 ecr 3951610201], length 256
21:44:33.211216 IP 192.168.1.1.632 > 192.168.1.94.33344: Flags [.], ack 257, win 235, options [nop,nop,TS val 3951610207 ecr 326702643], length 0
21:44:33.224972 IP 192.168.1.1.632 > 192.168.1.94.33344: Flags [P.], seq 1:91, ack 257, win 235, options [nop,nop,TS val 3951610221 ecr 326702643], length 90
21:44:33.225287 IP 192.168.1.1.632 > 192.168.1.94.33344: Flags [P.], seq 91:1048, ack 257, win 235, options [nop,nop,TS val 3951610221 ecr 326702643], length 957
21:44:33.228115 IP 192.168.1.94.33344 > 192.168.1.1.632: Flags [.], ack 91, win 343, options [nop,nop,TS val 326702647 ecr 3951610221], length 0
21:44:33.228187 IP 192.168.1.94.33344 > 192.168.1.1.632: Flags [.], ack 1048, win 350, options [nop,nop,TS val 326702647 ecr 3951610221], length 0
21:44:33.245059 IP 192.168.1.94.33344 > 192.168.1.1.632: Flags [P.], seq 257:264, ack 1048, win 350, options [nop,nop,TS val 326702652 ecr 3951610221], length 7
21:44:33.245659 IP 192.168.1.94.33344 > 192.168.1.1.632: Flags [R.], seq 264, ack 1048, win 350, options [nop,nop,TS val 326702652 ecr 3951610221], length 0

So it's indeed talking to the HTTPS port (632), but only for a few packets. That would match my assumption of an error during cert verification, but as I said: I wasn't offered a dialog to accept that cert.

@BenoitDuffez
Copy link
Owner

If it's self signed, did you add the root CA certificate into the trusted certificates in the OS?

@axel-1267
Copy link

axel-1267 commented Jan 10, 2023

I've got the same problem above. I'm using this app to print from a cups server running in a docker.

Very dirty solution:

  1. Add in cupsd.conf DefaultEncryption Required if not present.
  2. Add the printer on Android with https://***
  3. Try to print something, and fiddle back and forth from the document to AndroidCupsPrint.
  4. If you are lucky you get the prompt to trust connection and host.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants