Re: Problem with Line Spacing in Inkscape
Thank you for your help. Inkscape has wrote back, and the problem is known. It will be fixed in version 1.1.2 of Inkscape. Best regards Freddy Fisker On Friday, 14 January 2022 21:08:22 CET, Chris Cappuccio wrote: You should ask about this on Inkscape forums first Freddy Fisker [f...@freddyfisker.dk] wrote: There has for some time been a problem with the line spacing in version 1.1.1p1 of Inkscape. In a text the first two lines has one line spacing, and the next lines has the double line spacing. Opening older Inscape documents, the same problem occures - even though ...
Re: ttyflags hangs on Dell PowerEdge R200
On Fri, Jan 14, 2022 at 10:41:52PM +0100, Jan Stary wrote: > I suspect it's com1; I have yet to try commenting out just tty01. > But commenting out both makes it boot OK. > > com0 at acpi0 COMA addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo > com1 at acpi0 COMB addr 0x2f8/0x8 irq 3: ti16750, 64 byte fifo > > Are these known to misbehave under ttyflags? > > I realize a lot has changed since then, but it's a production machine, > and while I would love nothing more than go through the releases one > by one, this machine has to run now. Well there were recently changes to make com attach via acpi, and now you have a com port that you didn't have before. My suspicion would be that the new com1 either does not really exist in hardware, or that it's mis-configured. Does the BIOS mention it? Can it be disabled there?
ttyflags hangs on Dell PowerEdge R200
This is current/amd64 on a Dell PowerEdgee R200 (dmesg below). Right after install, the first boot hangs after checking the filesystems. Looking at /etc/rc in single user mode (adding set -x), it's apparently the ttyflags -a call; indeed, commenting that out makes it boot OK. I am now aware of three ways to work around it: 1. disable com in the kernel 2. comment out ttyflags in /etc/rc 3. comment out tty00 and tty01 in /etc/ttys I find 3. preferable; in absence of an actual fix, what would people suggest? This machine was last upgraded in 2015 (yeah, 5.8) so that's the only comparison I have for now. Full dmesg also below; beside renaming etc, the actual difference seems to be this: +acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x +acpicmos0 at acpi0 +com0 at acpi0 COMA addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo +com1 at acpi0 COMB addr 0x2f8/0x8 irq 3: ti16750, 64 byte fifo +com1: probed fifo depth: 0 bytes -com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo -radeondrm0: 1024x768 +radeondrm0: RV100 +[drm] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) +[drm] *ERROR* radeon: cp isn't working (-22). +drm:pid0:r100_startup *ERROR* failed initializing CP (-22). +drm:pid0:r100_init *ERROR* Disabling GPU acceleration +radeondrm0: 1280x1024, 16bpp So the old kernel, which booted fine, didn't have com1; and the drm errors were not reported. Disabling drm and/or radeondrm makes no difference w.r.t. the hang; disabling com makes it go away. I suspect it's com1; I have yet to try commenting out just tty01. But commenting out both makes it boot OK. com0 at acpi0 COMA addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo com1 at acpi0 COMB addr 0x2f8/0x8 irq 3: ti16750, 64 byte fifo Are these known to misbehave under ttyflags? I realize a lot has changed since then, but it's a production machine, and while I would love nothing more than go through the releases one by one, this machine has to run now. Jan OpenBSD 7.0-current (GENERIC.MP) #0: Fri Jan 14 20:56:22 CET 2022 h...@toposym.fit.cvut.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4276822016 (4078MB) avail mem = 4130037760 (3938MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xcff9c000 (46 entries) bios0: vendor Dell Inc. version "1.4.3" date 05/15/2009 bios0: Dell Inc. PowerEdge R200 acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC SPCR HPET MCFG WD__ SLIC ERST HEST BERT EINJ SSDT SSDT SSDT acpi0: wakeup devices PCI0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E3120 @ 3.16GHz, 2000.38 MHz, 06-17-0a cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 6MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 333MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(R) CPU E3120 @ 3.16GHz, 2000.15 MHz, 06-17-0a cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEX1) acpiprt2 at acpi0: bus 2 (SBE0) acpiprt3 at acpi0: bus 3 (SBE4) acpiprt4 at acpi0: bus 4 (SBE5) acpiprt5 at acpi0: bus 5 (COMP) acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x acpicmos0 at acpi0 com0 at acpi0 COMA addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo com1 at acpi0 COMB addr 0x2f8/0x8 irq 3: ti16750, 64 byte fifo com1: probed fifo depth: 0 bytes acpicpu0 at acpi0: C1(@1 halt!), PSS acpicpu1 at acpi0: C1(@1 halt!), PSS ipmi at mainbus0 not configured cpu0: Enhanced SpeedStep 2000 MHz: speeds: 3166, 2667, 2333, 2000 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 3200/3210 Host" rev 0x01 ppb0 at pci0 dev 1 function 0 "Intel 3200/3210 PCIE" rev 0x01: msi pci1 at ppb0 bus 1 mpi0 at pci1 dev 0 function 0 "Symbios Logic SAS1068E" rev 0x08: msi mpi0: SAS6IR, firmware 0.25.47.0 scsibus1 at mpi0: 112 targets sd0 at scsibus1 targ 0 lun 0: naa.600508e09ed329b65835f206 sd0: 69376MB, 512 bytes/sector, 142082048 sectors ppb1 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: msi pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02
Re: How to disable httpd's default
On Fri, Jan 14, 2022 at 07:50:36PM +, i...@protonmail.com wrote: > > It's not. Put the invalid block first and remove the wildcard block at the > > end. > > It doesn't work. Then the valid domains gets served with the > self-made certificate. It does work. You must have an error in your config file.
Re: Problem with Line Spacing in Inkscape
You should ask about this on Inkscape forums first Freddy Fisker [f...@freddyfisker.dk] wrote: > There has for some time been a problem with the line spacing in version > 1.1.1p1 of Inkscape. > > In a text the first two lines has one line spacing, and the next lines has > the double line spacing. > > Opening older Inscape documents, the same problem occures - even though > there was no problem writing the document. > > I can not imagine it is a regular change in Inkscape. > > I hope someone can help. > > Best regards > Freddy Fisker
Re: Invalid certificate, imaps connections fail (workaround)
On 2022-01-14, Randy Hartman wrote: > Hello, > > Just in case anyone else has the same problem... > > Both iPhone mail and mutt complained of an invalid certificate when > connecting to my mail server via imaps:// after certificate > expiration/renewal. The invalid certificate was installed by acme-client > from Let's Encrypt and sent out by dovecot. I removed the invalid > certificate and the email clients are working again. > > Inspecting fullchain.pem by itself was not enough to find the problem. I > noticed the invalid certificate by looking at the certificate path and > finding an expired self-signed root certificate. There were two > certification paths, one valid and one not valid. Clients are supposed to ignore the expired root certificate when there is a valid chain to an alternative root. There were problems with this in old clients; in OpenBSD/libressl this was fixed in -current and in syspatches. Not an iPhone user but I would assume that it should not be an issue in up-to-date versions of their software too.. > > Valid path: > > myserver, SHA256: > e661209d7c6a1779d35768eb53c4b60e0207cb97366796a056f56b367f2a9d48 > > R3, SHA256: > 67add1166b020ae61b8f5fc96813c04c2aa589960796865572a3c7e737613dfd > > ISRG Root X1 (Self-signed), SHA256: > 96bcec06264976f37460779acf28c5a7cfe8a3c0aae11a8ffcee05c0bddf08c6 > (Self-signed) > > > Non-valid path: > > myserver, SHA256: > e661209d7c6a1779d35768eb53c4b60e0207cb97366796a056f56b367f2a9d48 > > R3, SHA256: > 67add1166b020ae61b8f5fc96813c04c2aa589960796865572a3c7e737613dfd > > ISRG Root X1, SHA256: > 6d99fb265eb1c5b3744765fcbc648f3cd8e1bffafdc4c2f99b9d47cf7ff1c24f > > DST Root CA X3 (Expired Self-signed), SHA256: > 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739 > > -- Please keep replies on the mailing list.
Problem with Line Spacing in Inkscape
There has for some time been a problem with the line spacing in version 1.1.1p1 of Inkscape. In a text the first two lines has one line spacing, and the next lines has the double line spacing. Opening older Inscape documents, the same problem occures - even though there was no problem writing the document. I can not imagine it is a regular change in Inkscape. I hope someone can help. Best regards Freddy Fisker
Re: pfstat having trouble with current (with workaround)
On 2022-01-14, Christer Solskogen wrote: > If you see this: > > hugs# pfstat -q > ioctl: DIOCIGETIFACES: Operation not supported by device > pf_query: query_ifaces() failed > > And all of you packages are up-to-date(ish), force a reinstall pfstat and > everything is OK again. Sometimes a kernel ABI changes and userland programs need to be rebuilt to cope with that. Ports using the relevant interfaces should have the revision bumped to trigger updates. Sometimes we notice and have already done it but new packages haven't been built yet, but in this case we didn't notice. In this case it's because a new member was added to "struct pfi_kif", I will look for affected ports and bump REVISION on them now. If you see this again please report it as a bug (on ports@ would be better than misc as there's a higher chance it will get seen more quickly), ideally with dates of old+new kernels.
Re: problem with a mouse: attach/detach
On 2022-01-14, Rudolf Sykora wrote: > Dear list, > > > recently, I've been having a difficulty with my mouse. In > /var/log/messages I see a log like "recently" - can you think of any changes that might have started it happening? Probably worth filling in a sendbug template (or otherwise including the information that it gives, especially a full dmesg), and also including output from lsusb -v (from the usbutils package). > Jan 14 16:07:08 odin /bsd: uhidev0 at uhub4 port 1 configuration 1 > interface 0 "KYE NetScroll+ Traveler" rev 1.10/0.00 addr 4 > Jan 14 16:07:08 odin /bsd: uhidev0: iclass 3/1 > Jan 14 16:07:08 odin /bsd: ums0 at uhidev0: 3 buttons, Z dir > Jan 14 16:07:08 odin /bsd: wsmouse1 at ums0 mux 0 > Jan 14 16:07:32 odin /bsd: wsmouse1 detached > Jan 14 16:07:32 odin /bsd: ums0 detached > Jan 14 16:07:32 odin /bsd: uhidev0 detached > Jan 14 16:07:32 odin /bsd: uhidev0 at uhub4 port 1 configuration 1 > interface 0 "KYE NetScroll+ Traveler" rev 1.10/0.00 addr 4 > Jan 14 16:07:32 odin /bsd: uhidev0: iclass 3/1 > Jan 14 16:07:32 odin /bsd: ums0 at uhidev0: 3 buttons, Z dir > Jan 14 16:07:32 odin /bsd: wsmouse1 at ums0 mux 0 > Jan 14 16:07:33 odin /bsd: wsmouse1 detached > Jan 14 16:07:33 odin /bsd: ums0 detached > Jan 14 16:07:33 odin /bsd: uhidev0 detached > Jan 14 16:07:35 odin /bsd: uhub4: device problem, disabling port 1 > Jan 14 16:07:35 odin /bsd: uhidev0 at uhub4 port 1 configuration 1 > interface 0 "KYE NetScroll+ Traveler" rev 1.10/0.00 addr 4 > Jan 14 16:07:35 odin /bsd: uhidev0: iclass 3/1 > Jan 14 16:07:35 odin /bsd: ums0 at uhidev0: 3 buttons, Z dir > Jan 14 16:07:35 odin /bsd: wsmouse1 at ums0 mux 0 > Jan 14 16:07:36 odin /bsd: wsmouse1 detached > Jan 14 16:07:36 odin /bsd: ums0 detached > Jan 14 16:07:36 odin /bsd: uhidev0 detached > Jan 14 16:07:38 odin /bsd: uhub4: device problem, disabling port 1 > Jan 14 16:07:38 odin /bsd: uhidev0 at uhub4 port 1 configuration 1 > interface 0 "KYE NetScroll+ Traveler" rev 1.10/0.00 addr 4 > Jan 14 16:07:38 odin /bsd: uhidev0: iclass 3/1 > Jan 14 16:07:38 odin /bsd: ums0 at uhidev0: 3 buttons, Z dir > Jan 14 16:07:38 odin /bsd: wsmouse1 at ums0 mux 0 > Jan 14 16:07:49 odin /bsd: wsmouse1 detached > Jan 14 16:07:49 odin /bsd: ums0 detached > Jan 14 16:07:49 odin /bsd: uhidev0 detached > etc. > > I can use the mouse, it just stucks for a second or so from time to > time. I actually tried also another mouse, but it was the same. I also > tried a different USB port on my computer. > > I run OpenBSD 7.0 GENERIC.MP#3 amd64. > > Thank you for any comments and ideas how to resolve this. > > > Best regards > Ruda > >
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
OpenBSD default is for /etc/ssl/ to be root:wheel u+w,a+rx Harold, you broke your own machine. Stuart Henderson wrote: > On 2022-01-14, Harald Dunkel wrote: > > On 2022-01-14 10:42:56, Harald Dunkel wrote: > >> > >> Hi folks, > >> > >> trying to upgrade the installed packages I get > >> > >> # pkg_add -u > >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS > >> connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission > >> denied > >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect > >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied > >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty > >> Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... > > > > chmod a+rx /etc/ssl > > > > did the trick, but this doesn't look reasonable. > > Why would that not be reasonable? It's setting it back to the default > permissions after whatever change you've made to it. > > There are various system daemons and utilities (including sysupgrade, > syspatch, pkg_add, ntpd, rpki-client, syslogd, smtpd) that will > want to make TLS connections as a non-root user, at least in some > configurations. Some of these may open cert.pem while they still have > privileges but not always. > > > In general, if there is a permission problem due to file system > > access bits, then it would be wise to include euid and egid in > > the error message. > > Not sure if that helps really. If you'd seen that, maybe you would have > fixed it for _pkgfetch and not noticed some other software that would > like to use it.. > >
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On 2022-01-14, Harald Dunkel wrote: > On 2022-01-14 10:42:56, Harald Dunkel wrote: >> >> Hi folks, >> >> trying to upgrade the installed packages I get >> >> # pkg_add -u >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS connect >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect >> failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied >> https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty >> Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... > > chmod a+rx /etc/ssl > > did the trick, but this doesn't look reasonable. Why would that not be reasonable? It's setting it back to the default permissions after whatever change you've made to it. There are various system daemons and utilities (including sysupgrade, syspatch, pkg_add, ntpd, rpki-client, syslogd, smtpd) that will want to make TLS connections as a non-root user, at least in some configurations. Some of these may open cert.pem while they still have privileges but not always. > In general, if there is a permission problem due to file system > access bits, then it would be wise to include euid and egid in > the error message. Not sure if that helps really. If you'd seen that, maybe you would have fixed it for _pkgfetch and not noticed some other software that would like to use it..
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
| This happens on 2 OpenBSD hosts. On 5 others there is no such problem. Do you have an explanation why the 2 host out of 7 are behaving different? I don't find it "reasonable" that 2 host out of 7 manifest some different behavior on their own.
Re: How to disable httpd's default
On Fri, Jan 14, 2022 at 08:59:00AM -0500, Steven Shockley wrote: > Note that this does not require haproxy to have the client certificates, > since the hostname is transmitted in plaintext with SNI. At the moment, yes, but at some point we might implement ECH...
Re: How to disable httpd's default
On 1/13/2022 6:46 PM, i...@protonmail.com wrote:
I would like to avoid httpd giving anything if a user types in the IP
address of the server.
At first I just made an empty page, which is fine for port 80, but if
the user then types https://xxx.xxx.xxx.xxx, then the certificate for a
domain shows, which doesn't fit the IP address.
Is there some way to do something like:
server "default" {
listen on * port 80
listen on * port 443
block drop
}
And then only serve specific domains?
I've done something like this with haproxy using SNI routing, but for
different reasons. Unfortunately this requires running haproxy as root,
and haproxy has to be in the routing path. Having it on the same
machine is probably ok.
Note that this does not require haproxy to have the client certificates,
since the hostname is transmitted in plaintext with SNI.
Config snippets:
frontend ft_ssl_vip
bind :443
mode tcp
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
default_backend bk_ssl_default
backend bk_ssl_default
mode tcp
source 0.0.0.0 usesrc clientip
acl app_one req_ssl_sni -i one.example.com
acl app_two req_ssl_sni -i two.example.com
acl app_threereq_ssl_sni -i three.example.com
use-server one if app_one
use-server two if app_two
use-server three if app_three
use-server default if !app_one !app_two !app_three
option ssl-hello-chk
server one 1.2.3.4:443 check
server two 4.5.6.7:443 check
server three 7.8.9.10:443 check
server default 11.12.13.14:443
So, server default can answer with whatever cert you want, and one, two,
three can answer with their correct certs. Scanners won't connect to
one, two, three unless they already know the host names.
Of course, this is somewhat futile with Certificate Transparency, since
all your host names will be listed publicly anyway.
Re: How to disable httpd's default
On Fri, Jan 14, 2022 at 05:52:21AM -0700, Anthony J. Bentley wrote: > Crystal Kolipe writes: > > On Fri, Jan 14, 2022 at 01:49:01AM -0700, Anthony J. Bentley wrote: > > > The natural next question would be what leaks when someone accesses the > > > server using a made-up hostname. > > > > By 'made-up hostname', I'm assuming that you mean connecting to the server's > > IP address and then having the TLS handshake include an SNI field containing > > a domain name that is not listed in the public DNS for that IP, and for > > which the server is not specifically configured. > > > > In that case, what are you concerned about leaking? > > I understood the original question to mean a situation like: the server > is intended to serve pages for a given set of hostnames, including over > TLS; if an IP address or any other hostname is requested, then don't > serve any of those pages and don't leak any valid hostnames through the > certificate. That's a question I've had myself. Yes, I understood the question in the same way. > > I didn't suggest a 'fake' certificate. I suggested a certificate with a > > literal IP in the CN and SAN fields. This would be the correct certificate > > to present when connecting to the literal IP, and in the case of a 'made-up' > > hostname that the server doesn't actually host, a literal IP cert makes > > sense too. > > 'Fake' was not a judgmental term. I was suggesting that if there is > no intent to serve actual content when the user manually enters an IP > address, then there's no need for the certificate to manually specify > the IP I don't 100% agree with that assumption. > instead it makes more sense to generate a single catch-all > certificate for all invalid cases (many hostnames and potentially > multiple IP addresses). In that case, the reserved name "invalid" > makes sense, doesn't it? Well, I don't think that we should assume that a literal IP address and an invalid hostname are best treated in the same way. Assuming that the server config is correct, and that all DNS entries are correct, then requesting an invalid hostname makes no sense. There is no sensible response, and the request is likely to be coming from an unwanted bot anyway. So no point in serving any content, and since they already know your IP, nothing to gain or lose by serving a cert with just that IP in the CN and SAN. In the case of a request for a literal IP, that does potentially have a genuine use-case. Somebody debugging a problem with a broken client, network issue, DNS resolution problem, etc, etc. Ideally in this case, you would serve no http content, but with a real CA signed cert with the literal IP. That way, the client knows that they actually reached the intended machine, (no MITM), and can assume that the decision to serve no content was intentional. Since such a cert is not available free of charge, and most people would not want to pay for one, you can either use a cert for your real domain, (which we do), or a cert for a junk domain that you don't use, or a self-signed cert. I think that a self-signed cert for the literal IP case looks more professional, but at the end of the day, I suppose it doesn't really matter.
Re: How to disable httpd's default
Crystal Kolipe writes: > On Fri, Jan 14, 2022 at 01:49:01AM -0700, Anthony J. Bentley wrote: > > The natural next question would be what leaks when someone accesses the > > server using a made-up hostname. > > By 'made-up hostname', I'm assuming that you mean connecting to the server's > IP address and then having the TLS handshake include an SNI field containing > a domain name that is not listed in the public DNS for that IP, and for > which the server is not specifically configured. > > In that case, what are you concerned about leaking? I understood the original question to mean a situation like: the server is intended to serve pages for a given set of hostnames, including over TLS; if an IP address or any other hostname is requested, then don't serve any of those pages and don't leak any valid hostnames through the certificate. That's a question I've had myself. > I didn't suggest a 'fake' certificate. I suggested a certificate with a > literal IP in the CN and SAN fields. This would be the correct certificate > to present when connecting to the literal IP, and in the case of a 'made-up' > hostname that the server doesn't actually host, a literal IP cert makes > sense too. 'Fake' was not a judgmental term. I was suggesting that if there is no intent to serve actual content when the user manually enters an IP address, then there's no need for the certificate to manually specify the IP; instead it makes more sense to generate a single catch-all certificate for all invalid cases (many hostnames and potentially multiple IP addresses). In that case, the reserved name "invalid" makes sense, doesn't it? Regardless, you're right, specifying the invalid block first and dropping the wildcard block does work as expected in this situation.
pfstat having trouble with current (with workaround)
If you see this: hugs# pfstat -q ioctl: DIOCIGETIFACES: Operation not supported by device pf_query: query_ifaces() failed And all of you packages are up-to-date(ish), force a reinstall pfstat and everything is OK again.
Re: OpenSMTPd: Unable to use TLS/SSL over IPv6
Hey, On 14/01/2022 09:19, Stuart Henderson wrote: That hostname doesn't match the certificate, it should validate ok for storm-peaks.northrend.azeroth.wow-data.net (I also checked with -servername to send SNI). There's no difference between v4 and v6 for that though. thank you very much for spending time in testing this again. Sadly i cannot reproduce the issue. For me the certificate validates correctly for the hostname storm-peaks.northrend.azeroth.wow-data.net. I also used a couple of online certificate checking tools and they also report that it works fine. (https://www.hardenize.com/report/storm-peaks.northrend.azeroth.wow-data.net/1642159474#email and https://www.hardenize.com/report/storm-peaks.northrend.azeroth.wow-data.net/1642159474#email) I read the OpenSMTPd code again last night and i cannot reproduce the initial issue. There is basically no difference in IPv4 and IPv6 connections when they arrive at OpenSMTPd. Its just an open socket and then OpenSMTPd operates on that completely ignoring the IP version. I grepped the log files and in the last 7 days i had 263183 connections via IPv6 to OpenSMTPd. 82% of them used TLS (ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 beeing the most used) according to the log. So i think this should be fine. Thanks for everyone spending time looking into this, but i don't think its a configuration or OpenBSD issue at this point. Thanks so much and greetings Leo
Re: OpenSMTPd: Unable to use TLS/SSL over IPv6
Hey, On 14/01/2022 08:31, Crystal Kolipe wrote: Reading the manual page for openssl, specifically the section on s_client would be a very good idea. thank you for the hint. I did not know about this behavour. It does not explain the initial bug, but certenly my testing of it. For the archive, here is the important part from the manual. If a connection is established with an SSL server, any data received from the server is displayed and any key presses will be sent to the server. When used interactively (which means neither -quiet nor -ign_eof have been given), the session will be renegotiated if the line begins with an R; if the line begins with a Q or if end of file is reached, the connection will be closed down. Thanks for letting me know :)
Re: How to disable httpd's default
On Fri, Jan 14, 2022 at 03:21:03AM -0700, Anthony J. Bentley wrote: > From that I would expect to be able to create server blocks enumerating > valid hostnames, name the last block "*", and specify a self-signed > certificate with a domain name of "invalid". You just commented in another mail in this thread that you considered 'manually generating fake certificates' to be the wrong solution! > I can "force" the desired behavior by duplicating the invalid block > to mention that certificate first. But it doesn't seem like that > should be necessary. It's not. Put the invalid block first and remove the wildcard block at the end.
pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
Hi folks, trying to upgrade the installed packages I get # pkg_add -u https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... How comes? I am root. And openssl x509 -in /etc/ssl/cert.pem shows that I can read the certificate. This happens on 2 OpenBSD hosts. On 5 others there is no such problem. All use 7.0. http/tcp and https/tcp are not blocked by some forgotten pf rules. Every helpful hint is highly appreciated. Harri
Re: How to disable httpd's default
On Fri, Jan 14, 2022 at 01:49:01AM -0700, Anthony J. Bentley wrote: > Crystal Kolipe writes: > > On Thu, Jan 13, 2022 at 11:46:18PM +, i...@protonmail.com wrote: > > > I would like to avoid httpd giving anything if a user types in the IP > > > address of the server. > > > > > > At first I just made an empty page, which is fine for port 80, but if > > > the user then types https://xxx.xxx.xxx.xxx, then the certificate for a > > > domain shows, which doesn't fit the IP address. > > > > Why not create a dummy self-signed certificate that only has the IP > > address and no domain names? > > The natural next question would be what leaks when someone accesses the > server using a made-up hostname. By 'made-up hostname', I'm assuming that you mean connecting to the server's IP address and then having the TLS handshake include an SNI field containing a domain name that is not listed in the public DNS for that IP, and for which the server is not specifically configured. In that case, what are you concerned about leaking? The IP is already known, so presumably you are either concerned about leaking a hostname that is actually served, or details of the server and operating system in use. > Manually generating fake certificates feels like the wrong solution for this. I didn't suggest a 'fake' certificate. I suggested a certificate with a literal IP in the CN and SAN fields. This would be the correct certificate to present when connecting to the literal IP, and in the case of a 'made-up' hostname that the server doesn't actually host, a literal IP cert makes sense too. Of course, you can't easily or cheaply get a certificate for a literal IP address that is signed by a recognised CA. The original poster doesn't tell us his exact requirements or motives for setting up this server, so I'm assuming that it's a personal webserver. In that case, a self-signed cert for the fall-back literal IP case seems like the best option. In our case, we just present the cert for exoticsilicon.com for any requests to the literal IP, or any non-recognised domain. This leaks nothing as of course we have dns ptr records for the IPs, which resolve to subdomains of exoticsilicon.com. If you access the literal IP, or put an invalid hostname in SNI, the server presents the cert but serves no http content. The only exception is if you issue an invalid http request, for example, then you get a 400 error page served back. In our case that has been customised, so it shows references to exoticsilicon, but most users will just get a generic 400 bad request from httpd. So at most, you leak details of the operating system and webserver, and that works over plain unencrypted http as well, anyway, even using the 'block drop' directive, (which may in itself be a bug?)
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On 2022-01-14 10:42:56, Harald Dunkel wrote: Hi folks, trying to upgrade the installed packages I get # pkg_add -u https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS connect failure: failed to open CA file '/etc/ssl/cert.pem': Permission denied https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty Couldn't find updates for bash-5.1.8 bzip2-1.0.8p0 ... chmod a+rx /etc/ssl did the trick, but this doesn't look reasonable. In general, if there is a permission problem due to file system access bits, then it would be wise to include euid and egid in the error message. Harri
Re: How to disable httpd's default
i...@protonmail.com writes:
> I would like to avoid httpd giving anything if a user types in the IP
> address of the server.
httpd.conf(5) says:
server name {...}
Match the server name using shell globbing rules. This can be an
explicit name, www.example.com, or a name including wildcards,
*.example.com.
>From that I would expect to be able to create server blocks enumerating
valid hostnames, name the last block "*", and specify a self-signed
certificate with a domain name of "invalid".
So I tried it:
server "example" {
listen on * port 80
listen on * tls port 443
tls certificate "/etc/ssl/example.crt"
tls key "/etc/ssl/private/example.key"
}
server "*" {
listen on * port 80
listen on * tls port 443
tls certificate "/etc/ssl/invalid.crt"
tls key "/etc/ssl/private/invalid.key"
block
}
Results:
- http://example/ displays index.html (expected)
- http://127.0.0.1/ displays 403 (expected)
- http://noexist/ displays 403 (expected)
- https://example/ displays index.html, cert for example (expected)
- https://127.0.0.1/ displays 403, cert for example (unexpected)
- https://noexist/ displays 403, cert for example (unexpected)
Is that a bug?
I can "force" the desired behavior by duplicating the invalid block
to mention that certificate first. But it doesn't seem like that
should be necessary.
server "invalid" {
listen on * tls port 443
tls certificate "/etc/ssl/invalid.crt"
tls key "/etc/ssl/private/invalid.key"
block
}
server "example" {
listen on * port 80
listen on * tls port 443
tls certificate "/etc/ssl/example.crt"
tls key "/etc/ssl/private/example.key"
}
server "*" {
listen on * port 80
listen on * tls port 443
tls certificate "/etc/ssl/invalid.crt"
tls key "/etc/ssl/private/invalid.key"
block
}
- http://example/ displays index.html
- http://127.0.0.1/ displays 403
- http://noexist/ displays 403
- https://example/ displays index.html, cert for example
- https://127.0.0.1/ displays 403, cert for invalid
- https://noexist/ displays 403, cert for invalid
Re: How to disable httpd's default
Crystal Kolipe writes: > On Thu, Jan 13, 2022 at 11:46:18PM +, i...@protonmail.com wrote: > > I would like to avoid httpd giving anything if a user types in the IP > > address of the server. > > > > At first I just made an empty page, which is fine for port 80, but if > > the user then types https://xxx.xxx.xxx.xxx, then the certificate for a > > domain shows, which doesn't fit the IP address. > > Why not create a dummy self-signed certificate that only has the IP > address and no domain names? The natural next question would be what leaks when someone accesses the server using a made-up hostname. Manually generating fake certificates feels like the wrong solution for this.
Re: OpenSMTPd: Unable to use TLS/SSL over IPv6
On 2022-01-13, Crystal Kolipe wrote: > On Thu, Jan 13, 2022 at 05:25:41PM +, Stuart Henderson wrote: >> On 2022/01/13 18:05, Leo Unglaub wrote: >> > Hey, >> > >> > On 11/01/2022 21:28, Stuart Henderson wrote: >> > > I bet it is MTU related. Try lowering MTU on that interface (you >> > > cannot do it separately for IPv4 and IPv6 so it will change both, >> > > but that's not likely to be a problem) and get someone who has >> > > seen the problems to re-test. >> > >> > thank you so much for your answer. I would have never ever thought about >> > the >> > MTU in this case. I used the default 1500. I talked to the technical >> > support >> > from the datacenter (Hetzner Online) and they asured me that 1500 is >> > correct. >> > >> > However, i have set the value to 1400 and asked some people who had the >> > issue to re-test it. I will post the results of the test here so other >> > people can find them via a search engine. >> > >> > Thank you so much, very kind of you! >> >> The possible issue is that many people (especially people connecting >> over tunnels, but also those on pppoe) are on lower MTUs than this. >> Normally this is OK as fragmentation-needed messages will sort things >> out but sometimes firewalls are not be configured to pass these which >> will cause problems. If that _is_ what's happening then there are >> other ways to fix it but changing MTU is often the easiest one that >> you can do yourself. > > Well, I can connect to his server using: > > openssl s_client -starttls smtp -connect mail.unglaub.at:25 > > The handshake completes and I'm able to issue smtp commands. > > However smtpd always reports that opportunistic TLS failed, and > downgrades to plaintext. That hostname doesn't match the certificate, it should validate ok for storm-peaks.northrend.azeroth.wow-data.net (I also checked with -servername to send SNI). There's no difference between v4 and v6 for that though.
